Debuging...

Can't you just reproduce the bug inside the debugger? That would be a lot easier. If the program is not many lines long try stepping line by line. Or print messages from the program to locate the function like:
cout << "entering function blabla..\n";

Well, the program is ~27k lines, and its a game, so I cant really print somewhere. Of course I've tried to reproduce the bug inside the debuger, oh, man, how I've tried, but without luck, so maybe, this is caused by an uninitialized variable, that gets initialised to 0 when running inside the debuger and doesnt, when outside.

You could try creating a map file when you build, then using it to find out what function the program was in(that is, where is the instruction at 0x77fcb3ad) when it crashed.

Codeproject has an ok article at http://www.codeproject.com/debug/mapfile.asp

Doing this will get you close to where the crash is happening.

--
-Halo7

if you want to really continue to go the zen way here's the deal. the 0x77fcb3ad is just a hex address of the command that tried to access a NULL variable. some possible things that could have happened were that you may have overrun an array/buffer. you could be trying to dereference a pointer that is NULL. so if you want zen, just go through it that way.

otherwise there are ways to compile a Release build with symbols so that it'll run in the debugger but won't initialize your variables for you. google around or just play with your project settings to figure out how. or ask. :)

-me

The reason you can't reproduce it in the debugger probably is that the debugger will init vars to 0 for you but the release build won't so you probably have a check in your code that says:

if( pVar != NULL )
pVar->DoSomething();

As for debugging it. Just generate a map file and cross reference the crash with the address of a funciton in the map file.

Cheers
Chris

Sounds like the 'pass by value implicit dtor' rite of passage.

Are you passing objects by value? Do they have pointers? Do they delete the pointers and then 0 them out in the destructors? If so, consider passing by const reference or writing an appropriate copy constructor, operator= and constructors.

Thanks guys :)

Quote:

That does not make any sense. Why not? Everybody alse can do it, why can't you?

Well.. where should I write it? I have a OGL window open with a console, but if I output there I will not see the last message, since it just wont get to the swap buffers part... should I output to a file? But dont files open for writing get their last bytes trashed if it is not closed properly with fclose(), which will happen in case of a crash...

Quote:

Are you passing objects by value? Do they have pointers? Do they delete the pointers and then 0 them out in the destructors? If so, consider passing by const reference or writing an appropriate copy constructor, operator= and constructors.

I think I do pass that kind of classes using pointers... but I really hadnt thought if this, so I could have accidentally done it somewhere, I wouldnt be surprised if this is the case.

So map files it is, I'm starting to google to find a way to make them with DevC++, I dont see the options for it, maybe some console command?

[Edited by - Bouga on November 2, 2004 3:54:15 PM]

well you could output to a file and close it each time you write to it. or use a a catch(...) in your main and close the file then. or you could use sockets and send a syslog message to a client. kiwi syslog is a good one.

If you're making games and you want to debug games, you will learn the magic:

Use log files.

They are beautiful, beautiful things. Just have your program spit out whatever it's doing around where the bug happens to the log file, then use that information. That will give you somewhere to print. =)

As for your error, it sounds like a pointer issue...like you over or under-ran an array or tried to fire up a method that wasn't where you thought it was in memory.

Good luck.

Quote:

Use log files.

Hmm, use log files to record every function that is called during the every frame loop?

About the map files - what am I doing wrong? DevC++ usues MingW compiler, right? According to this: http://my.execpc.com/~geezer/osd/linkers.htm
I have to add this line to create a map file: -M, -Map FILE to the linker parameter string.

But when I do (I of course replace FILE with something like test.map), it gives me " E:\Dev-Cpp\MapTest\Makefile.win [Build Error] [maptest.exe] Error 1 "

Edit: Way off, nm.
--
-Halo7

The compiler option you want is:

-Wl,-Map,mapfilename.map

The map file generated with that is less informative than Visual C++, but it will at least get you to the function where your application is crashing.

--
-Halo7

Thank you very much :) But the wierd thing is, the error occurs at 0x77fcb3ad, but none of my functions go over 0x004****....

Don't go purely off the hex address in the file. When your program is loaded into memory, additional libraries are loaded into memory and their memory addresses may be changed (relocated). However, there is *no* reason for this to occur with a single EXE, nor should the module addresses ever go as high as 0x77fcb3ad.

Here's what I'd do.

Get a copy of WinDBG, and run your program through that (Open Executable). (WinDBG is Microsoft's half-GUI, half-command line debugger that is freely available in Debugging Tools package.) If it crashes it should dump you to the call that is crashing and you can then show the call stack window to try and figure out where it is going astray. From a quick glance at the address it appears the crash is within a system DLL because the base address is so high.

Now, your optimization level may be such that the call stack window is very shallow (this is the case if the ebp pointer is used as an additional general purpose register I believe). If the call stack window appears to be legitimate, you can step up the stack until you are within your program's code address space (0x004xxxx). Then, use the map file to match the location of that up with what instruction is causing the problem.

If the call stack doesn't look usable, you can either compile and execute a unoptimized version, or get a copy of the VC++ 2003 toolkit and compile a release build with debugging symbols. The generated PDB files can then be used by WinDBG and displayed within it.