Click here to Skip to main content
13,558,664 members
Rate this:
Please Sign up or sign in to vote.
See more:
I have a mixed-mode C++ application (/Clr code with a native library), all compiled with VS 2008.

The Win32 platform build works fine. On the opposite, the x64 build crashes very quickly at application startup.

After laborious debugging, I observe that the creation of a global-scope object in the native library raises a heap corruption assertion (upon "dynamic initializer" invocation).

The code of the object constructor is not the cause.

What can I do ?
Posted 22-Dec-12 13:26pm
Sergey Alexandrovich Kryukov 22-Dec-12 20:07pm
It sounds like a real problem, maybe a difficult one, but I don't think your information would be enough to tell anything...
YvesDaoust 25-Dec-12 4:50am
I wonder what extra information I could provide.

I tried to reproduce this in a toy project, to no avail. I have other application projects using the same library, that seem to work fine. The application that crashes is a much bigger one, but identical settings are used.
YvesDaoust 27-Dec-12 5:47am
The situation has worsened a little: I have moved my global variables as static inside functions (that was relevant in my case). Now the Debug version does not crash anymore and the Release one still crashes, and does never trap into the debugger. So there is even less that I can investigate.
YvesDaoust 27-Dec-12 6:25am
Ooops, wrong, after a full rebuild it seems to work.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

It is possible, perhaps even likely, that some code that runs before the code that you found is what is causing the problem. That code overwrites the heap and then when your code runs it becomes corrupted due to the previous error.
YvesDaoust 25-Dec-12 4:34am
Yes, this is frequent. Impossible to trace as this is in system code and not trapped by the debugger.
jschell 26-Dec-12 13:43pm
The debugger can't trap something that isn't a problem. Until it reaches the problem area it isn't a problem.

Your other apps work because you are using the library differently and/or the execution path is different.

There are libraries that you can use with C++ that allow you to more easily find pointer problems however manual inspection is still your friend (noting again that the problem is caused by code other than that where the exception occurs.)
YvesDaoust 27-Dec-12 5:56am
I don't believe that the problem lies directly in my code. It occurs in an early stage of application loading. Only trivial constructors are called for a few static class instances (mere intialization of data members, if initialization at all). No heap allocation on my side (no malloc, no new, no pointer dereference).
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

It might be that I have solved the issue just by moving the global static variable declarations inside functions.

The problem has apparently disappeared. Hope it is not just because the new memory layout better hides some erratic memory reference...
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

Be careful of system exceptions that disappear by inexplicable code changes.

Those sorts of code changes modify the execution path - which by its very nature can make the system exception fail to appear WITHOUT fixing the problem.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy |
Web04-2016 | 2.8.180515.1 | Last Updated 27 Dec 2012
Copyright © CodeProject, 1999-2018
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100