Assertion is violated upon SFXEmitter deletion
by Ingo Seidel · in Torque Game Engine Advanced · 04/14/2010 (5:24 am) · 1 replies
Hi,
when our 3D window is closed, our application will crash with the failed
assertion:
"SimManager::deleteObject: Object has already been deleted"
We have now traced the issue to the deletion of the SFXSource whose deletion
is called from within the SFXEmitter class. The deletion takes place in the
SFX_DELETE macro:
In debugging mode, the SFXSource seems to refer to a bad pointer, but the
delete routine is entered anyways. Is it now safe to replace the if clause
of SFX_DELETE with:
With this approach the deletion code is not executed and the Assertion does
not occur. However, we are not sure if it is safe to do so and if this might
cause problems at other places. Does anyone know whether this is a valid
workaround or have any information on why the problem occurs in the first place?
thanks and best regards
Ingo
when our 3D window is closed, our application will crash with the failed
assertion:
"SimManager::deleteObject: Object has already been deleted"
We have now traced the issue to the deletion of the SFXSource whose deletion
is called from within the SFXEmitter class. The deletion takes place in the
SFX_DELETE macro:
#define SFX_DELETE( source )
if ( source )
{
source->deleteObject();
source = NULL;
}In debugging mode, the SFXSource seems to refer to a bad pointer, but the
delete routine is entered anyways. Is it now safe to replace the if clause
of SFX_DELETE with:
... if (source && ! source->isDeleted() && ! source->isRemoved()) ...
With this approach the deletion code is not executed and the Assertion does
not occur. However, we are not sure if it is safe to do so and if this might
cause problems at other places. Does anyone know whether this is a valid
workaround or have any information on why the problem occurs in the first place?
thanks and best regards
Ingo
Torque 3D Owner Bloodknight
Bloodknight Studios
www.torquepowered.com/community/forums/viewthread/93879
I'm not sure but i think these changes were made in 1.8.2 so should be immune form this particular error.
Hope that helps