Debugging the release version of a program

Something a lot of programmers don't know is that you can debug the release version of a program as easy as the debug version. I didn't know this until I've read John Robbins 'Bugslayer' column in the 'Microsoft System Journal', April 1998 (Vol 13, No 4):

In MSVC you can set all of your project's configurations in the Project Settings dialog.

1.Select the All Configurations option in the Settings For combobox.
2.On the C/C++ tab, select Program Database in the Debug info combobox.
3.On the Link tab, with the Category combobox on Debug, check the Debug info checkbox and the Microsoft format.

If you use your own make file use /Zi switch with CL.EXE and use the use the /DEBUG and /PDB: switches for LINK.EXE,
That's all there is, now you can set breakpoints and watch variables as usual. Be aware that due to the optimizer not all symbols can be watch and the execution of the line may be in a different order!

A common error that affects only the release version of a program is when you use ASSERT instead of VERIFY. Remember ASSERTs will compile to nothing in a release version but VERIFY does. So if you call a function like ASSERT(DoSomething()) this function will not be called in the release version!

A release version of a program can behave different than the debug version due to optimzier settings. If you find a strange/buggy behavoir disable every optimazion and try again.



Comments

  • How to Debug CPaint?

    Posted by Legacy on 12/01/2003 12:00am

    Originally posted by: V.Ravendra Kumar

    Icons have been added against menu. Now I want to change the icons. How to debug the code regarding that.

    Reply
  • How to debug another exe from existing application.

    Posted by Legacy on 01/02/2003 12:00am

    Originally posted by: shashi

    I have an application (vc++6.0), which calls another application (vc++ 6.0), which is on same machine. When i try to debug by putting break points in the called exe code, its not going into the code (called exe code). Can any one help me in this?

    Reply
  • Regarding assert

    Posted by Legacy on 12/04/2002 12:00am

    Originally posted by: Low Chee Kong

    Hi,

    Like to find out whether there is a way to hide the assert message from showing up for testing purposes.

    I try using catch exception. However, it still shows up.

    Thanks!

    Reply
  • a hi !

    Posted by Legacy on 11/01/2002 12:00am

    Originally posted by: kenhan

    iwant to read your commet list and your news ! so you send to my E-Mail
    thank you

    Reply
  • debugging information not in precompiled heade

    Posted by Legacy on 10/18/2002 12:00am

    Originally posted by: Ralf Schneider

    if I turn on the described switches, I get the warning C4650 and the error C2859. They told me, that the precompiled header has no debug information. Accordingly I have to do something else.
    What do I have to do ????

    Reply
  • This is one step ahead

    Posted by Legacy on 09/03/2002 12:00am

    Originally posted by: nilesh Yeolekar

    Actually I was knowing how to get correct app runnig in release mode by disabling any optimization in the environment.But it seems to be one step ahead of what I was using uptill now.
    Thx very much.

    Reply
  • Really a good article !!

    Posted by Legacy on 08/10/2002 12:00am

    Originally posted by: Dilip Dave

    This is really good one !!
    

    Reply
  • "...debugging relase versions in MSVC..."

    Posted by Legacy on 03/21/2002 12:00am

    Originally posted by: Henry Park

    For a good reference on this topic see Chapter 7 in McKay & Woodring's, "Debugging With the Visual C++ Debugger". It outlines VC++ project settings that keep the debuggable release version file size as small as possible. It also discusses test phiosophy on release vs debug.
    

    Reply
  • global variables

    Posted by Legacy on 01/30/2002 12:00am

    Originally posted by: Patrick Vankeirsbilck

    good article!  It helped me a lot in the debug <-> release struggle.
    
    

    One remark though. Has anyone encountered a problem with global variable that seem to be unallocated in the release version?

    A short example:

    ------------------------------

    global.h:

    extern fstream tracefile;

    ------------------------------

    global.cxx:

    fstream tracefile("trace.txt");

    // and nothing else in this file (i.e. no explicit use of tracefile)

    ------------------------------

    I compile this with /O2 and /D NDEBUG under MSVC++ v6.0 with Service Pack 5 to make a static library, say globals.lib.

    Then there is a main.cxx:

    #include "global.h"

    int main()
    {
    tracefile << "Hello World" << endl;
    }

    which gets linked with the static library globals.lib.
    This crashes almost immediately at runtime. It works correctly when switching off /O2.
    Defining the tracefile variable in the main.cxx and removing the definition from global.cxx cures the problem.
    It looks like the optimizer thinks the tracefile variable in global.cxx is not needed and, hence, does not allocate it.

    Anyone has similar experiences in this matter?

    Reply
  • even worse things can happen

    Posted by Legacy on 12/08/2001 12:00am

    Originally posted by: Milan Stezka

    I've found that program behaving differently when built with release cofig is not the worst case. I've even ended up with program acting right when executed from the VC6 IDE and acting wrong when executed simply from Windows.

    Reply
  • Loading, Please Wait ...

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • The impact of a data loss event can be significant. Real-time data is essential to remaining competitive. Many companies can no longer afford to rely on a truck arriving each day to take backup tapes offsite. For most companies, a cloud backup and recovery solution will eliminate, or significantly reduce, IT resources related to the mundane task of backup and allow your resources to be redeployed to more strategic projects. The cloud - can now be comfortable for you – with 100% recovery from anywhere all …

  • It's time high-level executives and IT compliance officers recognize and acknowledge the danger of malicious insiders, an increased attack surface and the potential for breaches caused by employee error or negligence. See why there is extra emphasis on insider threats.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds