App runs in debug mode but crashes in release mode in Linux
by Mike Stoddart · in Torque Game Engine · 04/24/2005 (6:58 pm) · 5 replies
This is a pretty basic question, but what can I do if my app runs in debug mode but crashes in release mode before the opening screen is even displayed? This is using Fedora Core 3 and GCC is gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3).
I presume it's dying while setting up the magic stuff generated by the macros. I've added fxRenderObject and my own class based on item.cc and item.h.
Any suggestions appreciated!!
Thanks
I presume it's dying while setting up the magic stuff generated by the macros. I've added fxRenderObject and my own class based on item.cc and item.h.
Any suggestions appreciated!!
Thanks
#2
Thanks!
04/25/2005 (3:45 pm)
I've done many rebuilds and no I don't know what method it's dying in. I think I'll just re-implement it from scratch. I've been messing with the code quite a bit, so I probably forgot something simple.Thanks!
#3
If you can isolate the code down to a specific area, take something out (and it doesn't crash) and add it back in piece by piece (if you don't have too many dependencies), sometimes you can find it quickly. Otherwise, without some dev software intended to track down memory errors (something like boundschecker or great circle (I think is what its called)), its pretty much tough.
Of course, this could be a compiler bug, or even (horror!) an OS-related issue.
These are the things that make C/C++ fun.
Beyond that I'm afraid I can't give any better advice. If I'm correct (its very hard to say!), you'll just have to get creative if you don't have good memory-debugging tools.
04/25/2005 (5:24 pm)
Sounds like memory corruption. If so, those are usually nasty to track down, as its usually because of Pointers Gone Wild, a pointer being overwritten in release mode because debug mode often adds some extra "padding" and generally shuffles things around a bit more.If you can isolate the code down to a specific area, take something out (and it doesn't crash) and add it back in piece by piece (if you don't have too many dependencies), sometimes you can find it quickly. Otherwise, without some dev software intended to track down memory errors (something like boundschecker or great circle (I think is what its called)), its pretty much tough.
Of course, this could be a compiler bug, or even (horror!) an OS-related issue.
These are the things that make C/C++ fun.
Beyond that I'm afraid I can't give any better advice. If I'm correct (its very hard to say!), you'll just have to get creative if you don't have good memory-debugging tools.
#4
www.garagegames.com/mg/forums/result.thread.php?qt=28092
04/25/2005 (5:33 pm)
This might be of interest : www.garagegames.com/mg/forums/result.thread.php?qt=28092
#5
Thanks again!
04/25/2005 (5:36 pm)
Thanks guys. I asked on IRC and someone pointed me to a topic about GCC 3.4.1 bugs. I removed the -O2 from the makefile and it fixed the problem.Thanks again!
Associate Kyle Carter