Sigsegv On Quit()

#1 So I was wrong before about the Shutdown gui allowing this to work - it is a GuiFadinBitmalCtrl, copied directly from the Startup.gui, and all it does is call quit() after the fadein process is done. But even with this code in there, it still gets the SIGSEGV:

function escapeFromGame()
{
  if ( $Startup::fast ) {
    disconnect();
    loadShutdown();
    return;
  }
  ...
}

function loadShutdown()
{
  StartupGui.done = false;
  Canvas.setContent( ShutdownGui );
  schedule(100, 0, checkShutdownDone );
}
   
function checkShutdownDone()
{
   if (ShutdownGui.done)
     quit();
   else
      schedule(100, 0, checkShutdownDone );
}

But this is what's strange to me: If I just use schedule() to call quit() like this, it works fine, shuts down with no errors:

function escapeFromGame()
{
  if ( $Startup::fast ) {
    disconnect();
    schedule(1000, 0, quit );
    return;
  }
  ...
}

That is, this method works as long as the delay is long enough. If it is shorter, say 100 instead of 1000, then it still dies with a SIGSEGV.

I think that the only reason this isn't seen in normal use of TGE is because the default implementation of escapeFromGame() sends the user back to the MainMenu (in disconnect()), and then the user has to click on a button to quit -- which has some inherent delay, meaning that the even loop runs a few iterations, allowing the cleanup handlers to execute. But when I call quit() directly, that doesn't happen.

Can anyone explain this? Is there something else I can call directly to get the cleanup to happen correctly?

#2 You are just running into the need to give all of the destructors time to get called and have the object get cleaned up. It's not obvious from your stack trace, but you are most probably running into an Assert that is keeping track of the state of the bins, and complaining that cleanup wasn't complete.

#3 Basically, some particle emitters like to hang about until all their particles die. Which means they're in the scenegraph when it gets shut down. You can safely comment out the Assert, though it's useful for catching naught things like objects that don't remove themselves and just build up in the scenegraph, slowing things down and wasting resources.

#4 @Stephen
and
@Ben

Actually in our game we have noticed a problem with the actual memory value 0xCECECECE. The problem appears in simbase.cc in the following function (with the included but ugly hack).

SimObject::Notify* SimObject::removeNotify(void *ptr, SimObject::Notify::Type type)
{

   Notify **list = &mNotifyList;
   [b]if ((int)*list == (int)0xCECECECE) return NULL;  //Ugliness [/b]
   while(*list)
   {
      if((*list)->ptr == ptr && (*list)->type == type)
      {
         SimObject::Notify *ret = *list;
         *list = ret->next;
         return ret;
      }
      list = &((*list)->next);
   }
   return NULL;
}

If we don't put that line in, the program will crash. Of Note: We are running in Windows and at the moment I don't remember specifically when the crash happens or under what circumstances. I thought it was at some very random times. This bug is in 1.3 and 1.4.
-Joe

#5 Hmm, one thing I have noticed with shutting down is that the engine crashes if any sounds are left playing.