Debugging the web plugin

#1 Alright, I got some progress: I found a debugging tutorial at Mozilla's dev center, and they have a symbol server which makes the crash call stack more useful. I also downloaded mozzila-build, checked out the HG repo and pointed VC++ to it when it asks for Firefox sources, and now I get to see where the crashes are hapenning.

#2 Manoel,

Did you ever get anywhere with this? I'm currently in the same fix. Things seem to work ok on IE (which is a switch) but Firefox crashes as soon as it launches.

Thanks in advance,

= Ed =

#3 I really cannot remember what exactly the bug was, sorry. Our game was full of heap corruption problems (mostly due to our own code - the T3D ones I made sure to post about on the forums) and fixing them stopped the crashes.

To debug in FF you don't need the source. All you need it to tell VC++ where it can find the Firefox debugging symbols. In VC++ Options > Debugging > Symbols, add http://symbols.mozilla.org/firefox.

Now attach in VC++ go to File > Open > File. Open "firefox.exe". In FF, open the HTML with your game. When it crashes go to the call stack, right click on the greyed out stack entries (like XUL.dll!75f76f1e), now go to "Symbols" > "Load from symbol path" and wait while the symbols are downloaded.

When it's done you'll get a more detailed call stack. Do it for all greyed out entries (for the Windows DLLs you can use "Download from Microsoft servers").

#4 Thanks Manoel. I'll give it a go and report back. FWIW, from the console log it looks like it's dying either during or right after the reset of the display device from the resize command.

= Ed =

#5 BTW, if you use a debug version of your plugin so you step through it and set up breakpoints (in your code, not on the FF functions).

#6 Yeah, I figured that much out. Unfortunately, things seem to be dying in js3250.dll on a dtoa() call (that's all I can tell). The call stack shows nothing from my plugin. I've put in breakpoints in various places and the torque engine gets initialized just fine. I initially thought it might be the resize command that was causing it (from reading the console.log), but that does not appear to be the case.

I'm fairly confused as to how to proceed now. I'm guessing it's something in our GUI. I'm going to try to create a new project and see if that loads in Firefox or not. Then I'll try stripping out our gui from our project.

This stuff gets really messy - no real good way to debug it at all.

Thanks for the help and if you have any suggestions, let me know. I can give you the stack dump if you think that might help.

Thanks again.

= Ed =

#7 Seems you're falling around the same place I was. So this mean it's likely to be a heap corruption (the absolute worst part of C++) =/.

I remember the cause of the problem was coming from scripts. Disable the execution of everything, and see if it still crashes. Then progressively re-activate the scripts until it crashes, so you can nail down what is wrong.

If it is a heap corruption, it's likely to be happening when you run your game via the EXE, but it doesn't cause any crashes. Use GFlags.exe (msdn.microsoft.com/en-us/library/ff549561%28VS.85%29.aspx) to enable page heap verification

Beware: this will increase your game RAM usage a LOT, and you'll probably not be able to get past the menu before the game hits 2GBs and crashes. Don't use in a debug build - compile your release build with debug symbols instead. Also read on how to enable page heap only on the game DLL to keep it frmo using far too much RAM.

Also, prepare yourself for some headaches: heap corruption bugs are the most annoying ones to catch are are one of the things that can make you hate C++ and swear loyalty to Java/C# for life. The crashes rarely happen close to the offending code. Also, the offending memory addresses never repeat, and the crash location often changes in every execution.