Heap corruption at startup in mixed-mode x64 C++ application

Question

0.00/5 (No votes)

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

YvesDaoust

Add a Solution

Comments

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...
—SA

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.

3 solutions

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.

Posted 24-Dec-12 13:12pm

jschell

Comments

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).

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.

Posted 27-Dec-12 8:49am

jschell

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

YvesDaoust · Accepted Answer · 2012-12-27T00:29:00

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...

Posted 27-Dec-12 0:29am

YvesDaoust