I am experiencing a deterministic crash on the exit of my application. The application has been built as a MSVC2005 solution and one of the projects (the most critical wrt speed) has been compiled with Intel compiler.
The crash takes place during destruction of static objects. It is like these objects are destructed twice (so, the crash takes place when trying to free for 2nd time any memory they have allocated).
Any ideas where to start with?
I will exclude (b) & (c) since these objects are allocated/deallocated several times in the normal execution. It's only at exit that I get the crash.
So, what remains is... (a) & (d). If this gives any hint, note that the crash takes place not in a particular class but rather in all of the classes that envolve a static object.
The static object is created though as a parameter of another template one. The template class is a header file that is included multiple times. Here is a very simplified pseudo code:
//--------------- HEADER FILE START --------------
//--------------- HEADER FILE END --------------
While using the VC compilers I never came to any problem, could that be the case here? That the compiler generates static objects that do not match against the constructors/destructors?
Now that I am thinking about it, I will try a simple remedy, by placing the definition of the static object in a source file and see what I get from that... Any other ideas are welcomed!
Sorry, I was in a hurry and my post was not very clarifying.
The objects ARE static, but they allocate memory (on the heap). The address that I had printed is the static object address (and not the heap address of its allocated memory as perhaps incorrectly stated).
Printing the addresses from ctors/dtors gave me the problematic sequence of 2 ctors first then followed by 2 dtors, all with the same address.
I understand. Since the workspace is BIG and there are quite many static objects, my guess is that there might be such a case. BUT, it happens virtually for ALL static objects. If I change the code for one such class, so that it doesn't allocate any memory (and thus avoiding the crash), then I get a crash with another static object of a different class! So, my belief is that we are not talking with a particular bad reference case; it must be something more generic.
About linking order coming into play, that's surely the case. There are 3 projects and the static objects are created by headers of a template class - included by source files in all 3 projects.
thank you for providing a debugging method and putting effort on the problem.
Thank you Jennifer (& Jim) for your help. I will appreciate very much any information/progress related to this issue. In general, I would like to use the Intel compiler only for the most critical project where optimizations are necessary.
Please note that the test case does not make use of any special libraries (no MKL, no OpenMP, etc., just pure Ansi C++). Also, the bug appears already in debug mode, so it is irrelevant of any optimizations. The solution consists of a Win32 console application linked against a static library, both of them created as default projects from Visual Studio (the only change I made is unchecking precompiled headers).