I have this application that crashes before the main (even before the WinMainCRTStartup). It doesn't matter if I am compiling with optimizations "on" or "off". The weird thing is, it never crashes on the 32bit PC with the same visual studio 2005 installed. But it crashes about 30% of the time on the 64bit PC. Also, It doesn't matter if I compile in 32 bits or 64 bits; I get the same bug. I added a breakpoint in every static (singleton) class I had just in case, but I don't even get that far when it crashes. A little more info : -The only lib that I link with are OpenGL32, glu32 and OpenAL32. -I am building with the no common language support -When the crash happens, the callstack seems "broken", it's just hundreds of "ntdll.dll" with no symbols. -The crash seems like it can occur at different time. For example, sometimes I see in the ouput window that it crashed after loading the symbols for the .exe, but sometime it crashes after some .dll's symbols are loaded (can be any of the system's dll, opengl.dll or openal.dll). -Some builds seem "more stable" then others even if it's a minor change that has no real effects on the code. -I already installed VS2005 SP1 just in case.

Does it happen with a sample empty program that you compile yourself (for example a new console application)? If you don't know what else to do then you can always start from a working empty program and turn it into your problematic application bits by bits until it breaks.

Several things happen before main() is called. They include:

1. Vendor-supplied entry stuff. This is stuff the OS does to load the application into memory, allocate memory, setting up the stack and heap, and so on. It also loads the data segment and BSS, basically all the constants and space needed for your app to run.

2. Next is standard library initialization. This includes things like hooking up standard input and standard output, and starting up the C Run-Time (CRT) Library.

3. After the standard stuff is running, static objects are initialized.

4. Finally, the entry point main() is called.


Since the vendor supplied stuff and the standard library are used by about a bajillion applications, you can assume they are not the problem. That leaves static objects.

OpenGL32 and glu32 are both well tested. OpenAL32 is less tested, but still probably stable.

So next, you need to look at your own static objects.

These are global objects or functions called by them, such as:


int gSomeGlobal = func();
MySingleton MySingleton::mInstance;

In these cases, both the constructor for MySingleton and the function func() are called before main. This means that everything inside them is also called before main.

This gets back one of the good reasons why globals and singletons should be avoided.

Another reason that could also be the source of your bugs is The Static Initialization Order Fiasco (http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12) Basically, there are situations where you don't know the order of execution, so nasty bugs happen. The site does a good job explaining it, so I won't bother.

Unfortunately these can be hard to track down. It is best to avoid the situation entirely by avoiding global objects.


You are going to need one or more of these techniques:

You can drop breakpoints in all your static objects and see which is the last one to get run before it crashes.

You can use a debug version of the CRT. It can be a pain if you've never done it before. You will learn a lot about what happens before main() is called, but it can make hunting easier.

You can generate a map file, and compare the call stack (which you say is bad but probably is not corrupt) with the actual addresses inside your map file. You might be able to identify which object or function was involved.

There are other techniques you can use to track it down if those fail, but those should be enough.

Quote:
janta
Does it happen with a sample empty program that you compile yourself (for example a new console application)? If you don't know what else to do then you can always start from a working empty program and turn it into your problematic application bits by bits until it breaks.

It never crashes with sample programs. The project in question is quite big, testing it by adding small parts could take a long long while. Also, as I said, not only is it crashing about only 30% of the time, but sometime a build can be very stable; that could make it very hard/long to figure out if it's really the fault of a specific part of the code.

Quote:
frob
int gSomeGlobal = func();
MySingleton MySingleton::mInstance;

I don't have such global instances; ever. To access my singletons, I need to call a static function that allocates an instance. I still added a breakpoint in all of their constructor anyway ... but they were never hit when the crash occurred.

Quote:
You can generate a map file, and compare the call stack (which you say is bad but probably is not corrupt) with the actual addresses inside your map file.

Indeed it doesn't seem to be corrupted. After all, even though the symbols don't seem to be of any use, I do have addresses, well, one at least.

Quote:
You can use a debug version of the CRT

Yeah, that's a pretty good idea, I never tried, I guess there's a first time for everything.

If it's of any help, here's the output (the crash can occur anywhere between the game4.exe and any of the dll, this time it happened quite far in the process, but it is not unusual to crash after only 1 or 2 dll's.

note : in this specific crash, I had optimizations "on" and I was in 64 bits.




note : in this specific crash, I had optimizations "off" and I was in 32 bits.



[Edited by - crucifer on January 17, 2009 11:09:22 PM]