Quit() Causing Crash in Beta2

#1 Does your scene use particle emitters that your quitting from?

#2 No, it doesnt use particle emitters.

also, this crash happens even if I never actually get to the point of loading a mission. I experience this crash after loading the main menu and quitting immediately afterward. it seems to happen if I call quit() at any point after creating the canvas.

#3 Well build it in debug mode and add a break point in the AssertFatal platform stuff then make it crash.

#4 I use quit() to exit Torque applications 95% of the time so I can vouch that it works.

Does it work for you if you type it into the console?

#5 Just make games that people will never, ever want to quit playing!

Have you checked your console.log for Torquescript errors? Sometimes it'll print the faulty code with a pair of pound signs next to the error.

#6 - Chris,
I built the project in debug mode but the debug build isn't working! I get an error: Unable to load game library... Please make sure it exists and the latest DirectX is installed. Has anyone been able to successfully build and run the debug version of T3D B2?

- Matt,
like I mentioned, I get this error when I call quit() at any point after the canvas is created.

- Ray,
no errors in the console log... at all.

#7 Also, when I try to execute a debug session from the IDE(express 2005) it doesn't start. instead, a window pops up asking me which exe file to use for debugging.

shouldn't all this already be set up?

#8 If you haven't already, make sure you're running the latest DX SDK (June 2010). I would highly suggest upgrading to Visual Studio Express 2008. The 2005 solution was changed to a Pro one in 1.1 Beta 2 as Microsoft has discontinued it and no longer supports it.

#9 OK, I think I have found the source of this crash.

I spent the last couple hours tracking down the crash to the exact same place I originally suspected was causing the crash a few days ago: ModuleManager::shutdownSystem().

It looks like for some reason something in this function is causing the program to crash. when I remove this, no crash occurs.

#10 I'm still having this problem. In my custom script base, I'm getting a crash when attempting to quit the application by calling quit() from the main menu.

I dropped in a bunch of printf statements in each MODULE_SHUTDOWN to track which ones are being called and where it's stopping. the chain of modules shutting down always stops at Sim::shutdown(). I commented out the code in Sim::shutdown(), recompiled, and found this fixed the problem and the whole chain of modules were successfully shutdown.

I was then able to further narrow down the crash to shutdownRoot(). commenting out this line allowed all the rest of the modules to shut down as expected. something here is causing an error and crash while the program is shutting down.


Three things to note here:

1. I dont have an onExit() function defined.
2. the program isnt loading any missions, game objects, or datablocks before calling quit().
3. I don't get this crash when using any of the previous versions of T3D with this same script base.

#11 I have the same type of issue. But as I modified the C++ code, I need to recreate a std source code to test.

In fact, if I run the code in VS I can see that a Heap error occurred during the shutdown process.
I try to track down the issue, but I have difficulties as if I debug step by step, everything is working fine.
If you run it as an executable and not in VS env, everything is fine and no error occurred.

I will try to get more information of wait for Beta 3 to make additional tests.

My log:

GFXTextureObject::dumpActiveTOs - no active TOs to dump.
GFXPrimitiveBuffer::dumpActivePBs - no currently active PBs to dump. You are A-OK!
HEAP[game_DEBUG.exe]: HEAP: Free Heap block 7c21e60 modified at 7c226a8 after it was freed
Windows has triggered a breakpoint in game_DEBUG.exe.

This may be due to a corruption of the heap, which indicates a bug in game_DEBUG.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while game_DEBUG.exe has focus.

The output window may have more diagnostic information.

#12 Considering the sweeping changes to the scripting system in between Beta 1 and Beta 2, it is not surprising that it is a cause for instability. The reason why it doesn't crash outside of VS is not because everything is fine, or because no error occurred -- it's because it's not using the debug heap, and therefore isn't detecting the poor behavior.

#13 @Sean
Do you have this happening using stock T3D?

#14 @Scott
Yes this happens in stock T3D beta2. my scripts are custom but I haven't made any changes in the engine.

the only reason i bothered compiling it was to fix this problem.

#15 This may be a dumb question, but... If you don't have an onExit function, where exactly are you shutting down sfx, physics, and file change notifications? Could be one of those or something like it is causing the issues.

#16 It is a dumb question. The error is:

Quote:
HEAP[game_DEBUG.exe]: HEAP: Free Heap block 7c21e60 modified at 7c226a8 after it was freed

Upon reflection, do you think that error comes from not freeing something?

#17 @Daniel

I have a separate function end() which is called directly from a button on the main menu which handles those things. This function calls physicsdestroy(), exports prefs, calls stopfilechangenotifications, and then quit(). it's doing the same things just not using onExit().

also, I'm not calling sfxShutdown() nor sfxStartup(), if that makes any difference.

@Pat Wilson

I'm not sure whats causing this crash but I *AM* sure that insulting people isn't the solution.

#18 *final update*

OK, I finally figured this one out. after much trial and error, I eventually found the cause of the crash was the GuiControlProfiles I had defined. I truly hate torques control profiles, they have a history of crashing torque so easily.

Each and every one of the custom controlprofiles I had was crashing torque during shutdown. I'm not sure exactly why yet, but I removed them and replaced them with the default control profiles and not getting any crashes anymore. would this be considered a bug?

if you're using custom scripts and guis and are getting a crash at shutdown, your guicontrolprofiles may be the problem.

#19 Sean,

I track down my issue and I have the same issue as you.

And the strange thing is that, if I put them in the defaultGameProfiles.cs they are working perfectly.

I look in the init.cs and change the customProfile load to happen just before the default one and not before 2 other loading, and I still got my heap error.
fyi I raised this as a bug. here

#20 I logged elvince's bug report as TQA-1050. Watch that topic for updates.