Advertisement Jump to content
Sign in to follow this  
gjl

ASSERT triggered

This topic is 1725 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

 

after migrating from 2.28.0 to version 2.28.2 (rev 1887), I am getting a strange ASSERT on windows, in as_atomic.cpp (line 50):

asDWORD asCAtomic::get() const
{
// A very high ref count is highly unlikely. It most likely a problem with
// memory that has been overwritten or is being accessed after it was deleted.
asASSERT(value < 1000000);
 
It is triggered when releasing the script engine, apparently when going thru the special debug ValidateNoUsage function:
  msvcr110d.dll!_wassert(const wchar_t * expr, const wchar_t * filename, unsigned int lineno) Line 344 C
  asCAtomic::get() Line 50 C++
  asCObjectType::GetRefCount() Line 243 C++
  asCConfigGroup::ValidateNoUsage(asCScriptEngine * engine, asCObjectType * type) Line 221 C++
asCConfigGroup::RemoveConfiguration(asCScriptEngine * engine, bool notUsed) Line 164 C++
  asCScriptEngine::~asCScriptEngine() Line 678 C++
  asCScriptEngine::`scalar deleting destructor'(unsigned int) C++
  asCScriptEngine::Release() Line 797 C++
 
apart from this assert, there is no issue (no memory leak nor crash). Is this a known problem in a multithreaded environment (the script engine in this case is run in a specific thread), or is it possible that I am missing something important?

Share this post


Link to post
Share on other sites
Advertisement

I thought I had fixed this problem in revision 1880, but apparently there is some other scenario where it is still happening.

 

Unless you're facing a completely different problem, it is not related to multithreading, but rather that the clean-up of the data has a problem where the ValidateNoUsage() accesses the memory even after the object has been destroyed. As far as I could tell at the time this is only due to the debug code, as it is only ValidateNoUsage() that does this. You can comment out the call to the ValidateNoUsage() for now, as it is just an extra safe-guard I've put in the code to catch errors.

 

I still want to know more though, as I'll need to be able to reproduce this problem in order to fix it. Can you produce a small test case that reproduces the problem and share it with me?

Share this post


Link to post
Share on other sites

Thanks, that's what I thought too. I am still trying to find out the minimal scenario that triggers this. Right now it is only happening in a huge code base and basic test cases do not show this issue yet. :-(

Share this post


Link to post
Share on other sites

A quick update on this: after fixing my code (a call to Release on a script object missing) and properly calling asThreadCleanup(), the ASSERT is not triggered anymore. So it seems that there was actually a good reason for it!

Share this post


Link to post
Share on other sites

Thanks for the feedback. 

 

Hopefully I'll be able to figure out a way to provide a more friendly error message in this case.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!