locked
Application crashing in debug but running fine in Release mode RRS feed

  • Question

  • Hi

    I have an MFC dialog based application. This application is originally developed in visual c++ 6.0. Later it is migrated to VS 2003 and then to VS 2005. I was not part of the migration team. so i do not know about the changes that were made.

     

    Now i got an issue in the application. To understand the problem i need to debug the code. The applican is building without any errors in both debug and release modes. But the exe is crashing in debug mode but running fine in release mode.The application uses worker thread.Also it uses unicode character set.

     

    I observed that whenver any CString member is tried to set to the application object (using AfxGetApp()), it crashes in debug mode. It gives the following error.

    "Unhandled exception at 0x7832974c (mfc80ud.dll) in appXML.exe: 0xC0000005: Access violation reading location 0xfdfdfdf9."

    I feel that If there is any problem in the code, it shoud not work, it should not work in both release and debug modes. But it is working fine in release mode but crashing only in debug mode.

    Did anybody faced this situation?  Are there any settings that need to be modified in VS 2005 to get rid of this problem. please help me.


    Regards,
    Jaya Nageswar
    Thursday, January 8, 2009 7:04 AM

Answers

  • Why are you debugging the Release mode build?  You started your thread with "crashing in debug but running fine in release".  Diagnose the memory corruption problem in Debug mode first.  Much easier and it almost always solves a release mode issue as well.
    Hans Passant.
    Friday, January 9, 2009 2:45 PM

All replies

  •  Hi

    I have an MFC dialog based application. This application is originally developed in visual c++ 6.0. Later it is migrated to VS 2003 and then to VS 2005. I was not part of the migration team. so i do not know about the changes that were made.

     

    Now i got an issue in the application. To understand the problem i need to debug the code. The applican is building without any errors in both debug and release modes. But the exe is crashing in debug mode but running fine in release mode.The application uses worker thread.Also it uses unicode character set.

     

    I observed that whenver any CString member is tried to set to the application object (using AfxGetApp()), it crashes in debug mode. It gives the following error.

    "Unhandled exception at 0x7832974c (mfc80ud.dll) in appXML.exe: 0xC0000005: Access violation reading location 0xfdfdfdf9."

    I feel that If there is any problem in the code, it shoud not work, it should not work in both release and debug modes. But it is working fine in release mode but crashing only in debug mode.

    Did anybody faced this situation?  Are there any settings that need to be modified in VS 2005 to get rid of this problem. please help me.


    Regards,
    Jaya Nageswar
    Thursday, January 8, 2009 7:06 AM
  • 1. One reason might be, you have enabled UNICODE in release mode and in DEBUG mode you have not or viceversa.

    for example the following line will work fine if you have not enabled UNICODE.
    printf("Application Name: %s", AfxGetApp()->m_pszAppName);

    2. does your application uses any DLL? if so, read below
        We faced the similar problem with CString. We were constructing a CString object in one DLL and the destruction was happening in another dll. Check for that. Usually you should de allocate all the memory in the same module where you have allocated the memory.



    Pratap

    Thursday, January 8, 2009 7:27 AM
  • You can debug your code in release mode and find out the difference why it is working in release mode.
    Try to pinpoint the statement that doesn't work fine debug mode and works fine in release mode.
    So that you can locate the issue.

    Check this  link:
    http://weseetips.com/2008/11/16/how-to-debug-the-release-build/

    Thursday, January 8, 2009 9:15 AM
  • Probably you have a buffer overrun in your code that is not being caught in release mode, because it was built with the compiler flag /Gs-. When you run in debug code, the default buffer security check is Yes, i.e.,/Gs. That means any buffer overrun will be caught by a SEH setup around your main application.

    Thursday, January 8, 2009 11:21 AM
  • In Debug mode, the compiler injects code into your program that was designed to make it likely that it crashes when it does something wrong.  Examples are initializing stack variables to 0xcccccccc and heap blocks that are freed with 0xfeeefeee.  So that it is very likely you'll get an AccessViolation when you try to use an uninitialized pointer or a data from freed memory.  Very useful.

    0xfdfdfdfd is somewhat similar.  It is written before and after a heap block, "no-man's land", designed to detect buffer under- and overruns.  Your program is clearly reading a pointer value from a heap block at an invalid offset, getting the fence vaue.  That it doesn't crash in Release mode is just luck, your code has a time-bomb ready to go off right after you ship the app.  Debugging this should be simple, the function that commits the crime should be listed in the call stack.



    Hans Passant.
    Thursday, January 8, 2009 12:39 PM
  •  Since it's in debug mode, you can easily find out from where the call is coming using call stack. Please debug and allow teh application to crash (after attached to debugger). Get the call stack and chek from where this error came. Also verify the memory location. Verify the values involved in each functions in call stack. If you can find some pointer values, involved in this crash it's easy to detect as you can break at the modifying location. Put enough traces to make your debugging easy
    -Sarath. My blog - http://sarathc.wordpress.com/
    Thursday, January 8, 2009 12:48 PM
  •  What is your compiler warning level set to?
    Thursday, January 8, 2009 2:08 PM
  •   

    Thanks for the responses. I wanted to explain my problem in detail.I do not think the crash is occured because of dynamic memory allocation related issues. I have the following code snippet in my program.

    CERWXMLApp* pApp = (CERWXMLApp*)AfxGetApp();
    pApp->SetVersion(version);

    If i comment this code, I am getting the crash at some other location. The crash is occuring at some other place (not at the place when i am setting string using Application object.So i'm feeling that it may be related to some visual studio setting. But i do not know what it is.

    If i do not comment the above code i get the crash at the following highlighted line in thrdcore.cpp(C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src\mfc\thrdcore.cpp).

    BOOL __cdecl AfxIsIdleMessage(MSG* pMsg)
    {
      CWinThread *pThread = AfxGetThread();
      if( pThread )
     return pThread->IsIdleMessage( pMsg );
      else
     return AfxInternalIsIdleMessage( pMsg );
    }

    I am using worker thread in my application. I do not know whether this is caused by worker thread.

    Sometimes for the same piece of code crash occurs at the following line in atlsimp.cpp (C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\atlsimpstr.h)

     bool IsLocked() const throw()
     {
      return nRefs < 0;
     }

    I could not see entire stack heirarchy because it is showing the assembly instructions. It is not going to the source code even though i tried to used GO TO SOURCE CODE option from the menu which pops up by right clicking the mouse on assembly code.

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

    I tried to debug in release mode. I set the "Debug Information format" to "Program Database (/Zi)" under project properties -> C/C++ ->General and i set "Generate Debug Info" to "Yes (/DEBUG)" under project properties ->Linker->Debugging.

    I am able to put the break points in release mode and the code is getting stopped at the debug points but i am unable to see the values. (Eg. CString values are shown as <Bad Ptr> even though values are existing.). Do i need to change any other setting to view the values of variables, objects etc in releae mode like we do in debug mode. 



    Regards,
    jaya Nageswar



    Friday, January 9, 2009 2:27 PM
  •  

     

    Thanks for the responses. I wanted to explain my problem in detail.I do not think the crash is occured because of dynamic memory allocation related issues. I have the following code snippet in my program.

    CERWXMLApp* pApp = (CERWXMLApp*)AfxGetApp();
    pApp->SetVersion(version);

    If i comment this code, I am getting the crash at some other location. The crash is occuring at some other place (not at the place when i am setting string using Application object.So i'm feeling that it may be related to some visual studio setting. But i do not know what it is.

    If i do not comment the above code i get the crash at the following highlighted line in thrdcore.cpp(C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src\mfc\thrdcore.cpp).

    BOOL __cdecl AfxIsIdleMessage(MSG* pMsg)
    {
      CWinThread *pThread = AfxGetThread();
      if( pThread )
     return pThread->IsIdleMessage( pMsg );
      else
     return AfxInternalIsIdleMessage( pMsg );
    }

    I am using worker thread in my application. I do not know whether this is caused by worker thread.

    Sometimes for the same piece of code crash occurs at the following line in atlsimp.cpp (C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\atlsimpstr.h)

     bool IsLocked() const throw()
     {
      return nRefs < 0;
     }

    I could not see entire stack heirarchy because it is showing the assembly instructions. It is not going to the source code even though i tried to used GO TO SOURCE CODE option from the menu which pops up by right clicking the mouse on assembly code.

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

    I tried to debug in release mode. I set the "Debug Information format" to "Program Database (/Zi)" under project properties -> C/C++ ->General and i set "Generate Debug Info" to "Yes (/DEBUG)" under project properties ->Linker->Debugging.

    I am able to put the break points in release mode and the code is getting stopped at the debug points but i am unable to see the values. (Eg. CString values are shown as <Bad Ptr> even though values are existing.). Do i need to change any other setting to view the values of variables, objects etc in releae mode like we do in debug mode. 



    Regards,
    jaya Nageswar

    Friday, January 9, 2009 2:30 PM
  • Why are you debugging the Release mode build?  You started your thread with "crashing in debug but running fine in release".  Diagnose the memory corruption problem in Debug mode first.  Much easier and it almost always solves a release mode issue as well.
    Hans Passant.
    Friday, January 9, 2009 2:45 PM
  • At times it is possible that some operations work fine in Debug mode but not in Release mode and vice-versa.
     
    Here are the some of the common errors that lead us to the above problem.

    Check the _DEBUG macro in the code. where it is used and How it is used.
              Look for any code that is inside of a "#ifdef _DEBUG" wrapper that might be needed in the Release version.
     
    4.  Sometimes Warnings are important.
     
            When starting a project turn the warning level to "Level 3" or "Level 4" and  make sure the code compiles with minimal or no warnings.
    5.  Don't Remove Needed Code in Release
     
          There are several macros that are commonly used that are completely removed when you compile in release mode. 
          For example ASSERT macros and TRACE macros are quietly removed in Release builds. Any code that may be required, 
          which was to be executed in an ASSERT or TRACE command will also be removed.
     
    6.  Make the Debug mode more like Release
     
          Make the Debug mode more likely Release mode and Reproduce the problem in Debug mode.
          The main difference is _DEBUG macro is defined in Debug and NDEBUG macro is defined in Release.
          So, define NDEBUG in Debug instead of _DEBUG.
     
    7. Generally, we can debug the code in Debug but not in Release.
     
           But we can also debug the code in Release by setting "Generate Debug Info"  in Project Properties page -> Link -> Generate Debug Info

    Thanks

    Cheers, Eliza
    Wednesday, January 27, 2010 2:03 PM