Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++
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
Comments
Sergey Alexandrovich Kryukov at 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...
—SA
YvesDaoust at 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 at 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 at 27-Dec-12 6:25am
   
Ooops, wrong, after a full rebuild it seems to work.
Rate this: bad
good
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.
  Permalink  
Comments
YvesDaoust at 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 at 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 at 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
good
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...
  Permalink  
Rate this: bad
good
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.
  Permalink  

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

  Print Answers RSS
0 Maciej Los 580
1 OriginalGriff 443
2 CPallini 189
3 CHill60 180
4 Peter Leow 175
0 OriginalGriff 6,092
1 Sergey Alexandrovich Kryukov 4,958
2 Maciej Los 3,269
3 Peter Leow 3,129
4 DamithSL 2,490


Advertise | Privacy | Mobile
Web04 | 2.8.140721.1 | Last Updated 27 Dec 2012
Copyright © CodeProject, 1999-2014
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