Help with c++ debugging

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
Quall
Posts: 154
Joined: Mon Mar 07, 2005 10:16 pm

Help with c++ debugging

Post by Quall »

Hello, I had a year of schooling in java and along side it I was learning c++ on my own.

Java and c# don't have the need for memory clean up, everything is basically treated as a pointer (or in java terms, a "reference"), but you never have to return an address value. It is pretty self managing.

Anyways, I am trying to debug my c++ app, so I am still in the learning process. I had never had any problem until this past week. I removed everything I changed but my app still seems to crash. Most of my classes are static.

However, it crashes at the end of the main function. When I debug, it brings me to an assembly language file, which looks like it is reading the beginning of main.

crashes here (unhandled exception):

Code: Select all

#ifdef _WINDOWS
APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
#else
main()
#endif
{
	class GameManager* gamemanager;
	bool restart = true;
	while(restart)
		{
		gamemanager = new GameManager();
			std::cout<<"A new manager has been created\nRunning game loop now...";
		restart = gamemanager->Run();
			std::cout<<"exited\n";
			std::cout<<"Game manager will be destoyed...";
		//gamemanager->~GameManager();
		gamemanager = 0;
			std::cout<<"done\n";
		}
	std::cout<<"Goodbye\n";  

//IT CRASHES AFTER THIS COMMENT
};
debugs to here:

Code: Select all

main_loop:
        mov     eax,dword ptr [ecx]     ; read 4 bytes <--crashes here
        mov     edx,7efefeffh
        add     edx,eax
I just can't figure it out. Has anyone else had an app crash at this point?
Quall
Posts: 154
Joined: Mon Mar 07, 2005 10:16 pm

Post by Quall »

Nevermind, I am such a moron. I had a variabe called "config", which I thought I had declared as a pointer (it was not). I was setting it to 0 in the class's destructor.

I usually call the destructors myself, just to get used to cleaning up. Damn, I should have gotten the clue when it would crash there.
hybrid

Post by hybrid »

Maybe you should also start to call the destructor by delete gamemanager instead of calling it as a method. And main is int main(int argc, char* argv[]). So have fun with C++ :P
hybrid

Post by hybrid »

A question I have concerning debugging: What's the best way to debug an application under windows the same way as under Linux with gdb: Run the app, get a core dump and start the debugger with that core getting the stack trace and checking variables etc. And yes, I'm just learning those windows tools, I don't know anything about debugging under windows.
The stack trace of a VC debug version is a first step, but often not enough... But the debug option of VC++ usually gives me some microsoft header files as the source of the error, but no possibilities to walk the stack.
hybrid

Post by hybrid »

Ok, I see. No one's debugging under Windows, or is allowed to talk on this topic. I'll make it another way: My problem is that I always get "debug assertion failed" messages. But, the program runs perfectly under Linux, and I built the app and all libraries in release mode. What's wrong here? Even funnier, the app often runs after ignoring enough of these messages, but sometimes it simply stops.
And how can I tell which libraries I have to include (standard MS libraries) and which ones I have to exclude (with NOLIBS). It might be the case that I have too few, or wrong libraries here. It's really no fun to develop under Windows.
BTW: Why is the Win32-gcc without directX? Is there something illegal with passing on these builds?
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

The easiest way to debug under windows is to make a debug build of the irrlicht dll and your application. Then run under the debugger [press F5]. The debugger will stop program execution right when something goes wrong. Then you can look at the stack and stuff and figure out what to do from there. When the debugger has the program stopped, you can get a call stack by pressing Ctrl+Alt+C [or click Debug | Windows | Stack].

Also, just because the program runs fine under linux [or any other platform] does not mean that it is correct.

Travis
pfo
Posts: 370
Joined: Mon Aug 29, 2005 10:54 pm
Location: http://web.utk.edu/~pfox1

Post by pfo »

Also, just because the program runs fine under linux [or any other platform] does not mean that it is correct.
Very true, especially for release builds. When moving a project that works on one OS to another for testing, I would always do a debug build first and test it, or do that as soon as the release version failed. For the most part, a release build that fails for whatever reason will probably be nearly impossible to detect unless whatever failed handled its error gracefully.
hybrid

Post by hybrid »

Ahh, thanks for the hints. I could successfully find the location where Windows systems leave the glorious paths of C++ compatibility :? Dynamic casts can throw __non_rtti_object exceptions which seem to be MS artifacts. Of course, these were unhandled before, and they are simply ignored right now. So at least in this part I'd say my program has been correct before, and now I patched it for a workaround of compiler pecularities :wink:
hybrid

Post by hybrid »

Ok, a little update because it might be useful for others extending Irrlicht, too. The Irrlicht.dll distributed for VisualC++ seems to lack RTTI, so no chance to check if a scene node (ISceneNode*) is of a particular type.
We use dynamic_cast to check if a user selected scene node is capable of doing some special things we have added. This is still possible, as our code contains RTTI, so we just have to amend every dynamic_cast with this silly try catch to avoid the exception thrown due to missing RTTI. I think I have to setup my system to be able to recompile Irrlicht...
Post Reply