ASSERT triggered

Author

468

April 11, 2014 07:26 PM

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?

WitchLord

4,860

April 11, 2014 07:59 PM

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?

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

gjl

Author

468

April 12, 2014 11:26 AM

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. :-(

gjl

Author

468

April 29, 2014 07:26 PM

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!

WitchLord

4,860

May 01, 2014 03:07 PM

Thanks for the feedback.

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

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

ASSERT triggered

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

ASSERT triggered

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines