Debugging a release build with the Visual C++ 2005

Sometimes debug build doesn’t crash but release build crashes. This usually happens when memory area which is not valid is accessed. Debug build usually has some fence around allocated memory area.

However, recently I suffered somewhat different case. In this case, you need to debug a release build.
Yeah.. It is quite easy. Just enable debug information for a release build. However, in my recent case, doing so didn’t reveal symbols or display correct values for variables.
At first, I thought a stack is corrupted. However, I found out that optimization option did affect the symptom.

So, disabling optimization was the solution to check content of variables.
coptimization

The cause of the crash was due to #pragma pack.
In one of its header file, #pragma pack (push, 1) is used, and at the end of the file #pragma pack(pop, 1).
It should have been #pragma pack(pop) to reverting.

So, in a influenced class implementation file, it used correct alignment, while in other source file which included a troubled header file, the alignment of this class is not interpreted as it should have been.
So, it caused a vtable evasion in a source file which includes the troubled header file. Therefore, it crashed when it called one of the method of the influenced class.

It is strange that this didn’t cause problem with a debug build. There is not explanation on the MSDN site whether this is disabled in debug build or not.

2 responses to this post.

  1. Posted by Michael on February 12, 2010 at 12:38 AM

    Hello,

    I have the same problem with building a native application for a pocket pc. In debug mode nothing strange happens, but when I build a release executable – my application crashes. I suspect buffer overflow error somewhere, but I can’t find it without a break, that would occur at the general program exception that is generated by windows mobile system. As posted above – if I disable optimization everything will run very well. I tried to enable optimization in debug build to “catch” that error, but without success. Debugger is blind. I’m stuck:( Do you have any idea? I work on VS 2008 Professional.
    I would appreciate any suggestion.
    I apologize for my English:)

    Reply

    • Posted by jongampark on February 12, 2010 at 8:06 AM

      Hello.
      Yeah.. I’m aware of such problem. The easy case is when people put some ciritical codes for executing the app in ASSERT() macro. If it is release build, anything embraced by the ASSERT() is not included in compiled codes.
      A litter harder case is when accessing allocated memory invades unallocated area. What I mean is if your code accesses 11th position when only 10 elements are allocated. Sometimes things are not apparent. In debug mode, whenever it allocates memory, it pads “No Men’s Land” before and after the allocated block. So, if your codes try writing something in the “No Men’s Land”, the debugger can sense it. But if it happens with release build, it will crash.

      MFC does provides helper functions for any memory miss-use.
      Try looking at _CrtMemCheckpoint and others which are used to initiate memory checking and reporting the memory status.
      ( http://msdn.microsoft.com/en-us/library/hk1k7x6x%28VS.80%29.aspx has a list for those functions. )
      Also, to figure out what to do, and how to do, try reading this. http://msdn.microsoft.com/en-us/library/c99kz476%28VS.80%29.aspx

      If you use “new” and “delete” for allocating/deallocating memory, using DEBUG_NEW will help.

      Hope this helps… :)

      Reply

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: