Crash in SimObject::processDeleteNotifies
by Sim Ops Studios (#0003) · in Torque Game Engine Advanced · 09/01/2007 (12:53 pm) · 2 replies
We're experiencing a problem that is almost certainly our fault, but I'm having a very hard time understanding what might cause it. Any insight as to some useful directions to take with the debugging would be very much appreciated.
We currently crash whenever we attempt to unload our mission to load a new one (either selecting New Mission or Open Mission from the level editor's menu). I've been able to isolate the crash to this section of code inside SimObject::processDeleteNotifies():
if(note->type == Notify::DeleteNotify)
{
SimObject *obj = (SimObject *) note->ptr;
Notify *cnote = obj->removeNotify((void *)this, Notify::ClearNotify);
obj->onDeleteNotify(this);
freeNotify(cnote);
}
In this context, "this" is a custom SimObject we have designed that is ghosted; we are running processDeleteNotifies on the ghost. The problem we are encountering is that note->ptr is a bad pointer; the memory pointed to is uninitialized and we crash on obj->removeNotify.
Does anyone know what we may have done wrong to get into this state? To my knowledge, we aren't explicitly registering notification on this object in any of the code we have written, so I expected it to "just work." Any suggestions on how to move forward debugging this issue would be very much appreciated.
On a related note: Where are notifies added to the mNotifyList? Knowing that, we could match up the registration of the DeleteNotify message against the lifecycle of the object referenced in note->ptr and see if it's prematurely deleted.
Thank you for your help!
We currently crash whenever we attempt to unload our mission to load a new one (either selecting New Mission or Open Mission from the level editor's menu). I've been able to isolate the crash to this section of code inside SimObject::processDeleteNotifies():
if(note->type == Notify::DeleteNotify)
{
SimObject *obj = (SimObject *) note->ptr;
Notify *cnote = obj->removeNotify((void *)this, Notify::ClearNotify);
obj->onDeleteNotify(this);
freeNotify(cnote);
}
In this context, "this" is a custom SimObject we have designed that is ghosted; we are running processDeleteNotifies on the ghost. The problem we are encountering is that note->ptr is a bad pointer; the memory pointed to is uninitialized and we crash on obj->removeNotify.
Does anyone know what we may have done wrong to get into this state? To my knowledge, we aren't explicitly registering notification on this object in any of the code we have written, so I expected it to "just work." Any suggestions on how to move forward debugging this issue would be very much appreciated.
On a related note: Where are notifies added to the mNotifyList? Knowing that, we could match up the registration of the DeleteNotify message against the lifecycle of the object referenced in note->ptr and see if it's prematurely deleted.
Thank you for your help!
About the author
#2
The problem was living in another part of the code, where we had created a SimSet to keep track of objects that needed to be notified when certain conditions occurred. The SimSet was not initialized properly (registerObject was not called when it was created, nor was unregisterObject called when it was destroyed), and SimSets register themselves for delete notification on the objects they contain. The object that was getting the crash was registered with this SimSet.
I didn't follow the exact path through the code, but clearly being a member of a SimSet that is not registered properly is, understandably, a recipe for disaster when objects start getting deleted. I've added the proper registration calls and everything is peachy now.
Thanks for your help, it definitely pointed us in the right direction!
- lem.
09/02/2007 (11:10 am)
I managed to track this one down.The problem was living in another part of the code, where we had created a SimSet to keep track of objects that needed to be notified when certain conditions occurred. The SimSet was not initialized properly (registerObject was not called when it was created, nor was unregisterObject called when it was destroyed), and SimSets register themselves for delete notification on the objects they contain. The object that was getting the crash was registered with this SimSet.
I didn't follow the exact path through the code, but clearly being a member of a SimSet that is not registered properly is, understandably, a recipe for disaster when objects start getting deleted. I've added the proper registration calls and everything is peachy now.
Thanks for your help, it definitely pointed us in the right direction!
- lem.
Torque Owner Brian Richardson