Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 398
  • Last Modified:

Debug Assertion in Release build

I've build a large project, and have now tried to build it in release mode.  I get the following:
Debug Assertion Failed
File: dbgheap.c
Line 1051    ( I think this is in v_free_dbg)

The code that causes this is:

(in OnInitUpdate, this the setup and its OK)
               // Pre Bill Tab
    m_pbTab = new CPbInvDlgTab(m_client, m_matter, m_invList, this);
    VERIFY(m_pbTab->Create(CPbInvDlgTab::IDD, &m_wipTabCntl));


(OnDestroy)
    m_pbTab->DestroyWindow();
    delete m_pbTab;         // This blows up here with the debug assertion

(These are views that are used in a TAB control)

I have searched all though the code for any conditional  DEBUG code that may be getting included in the release mode.  The view getting destroyed has vendor provided OCXs.  As well I'm using third party STL lib, but I have included only their release LIBS.

A pointer as where to look next would be great help.  This all runs OK in DEBUG build. Am I on the right track in assuming that some DEBUG build code is doing a delete etc?

Chris Sadler

0
csadler
Asked:
csadler
  • 2
1 Solution
 
NorbertCommented:
is it possible that you deleted some
#ifdef _DEBUG
directives
at the beginning of the most appwizard /classwizzard generated files you found:

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

I don't know what happens in release build if these ifdef directive is deleted

BTW I am sure that some debug code is doing the delete
because assertions are impossible in release as I know

HTH
    Norbert
0
 
mikeblasCommented:
DBGHEAP.C comes from the debug version of the C runtime libraries. If you're getting an assertion in this module after a release build, you've not done a true release build: something's wrong with the way you're building, or something's wrong with the way one of your modules is linking.

Normally, an MFC application links to a particular set of runtimes based on _DEBUG being defined. AFX.H will emit a special record into the *.OBJ file of your application instructing the linker to go fetch the version of the runtime libraries that match the type of build you're preforming. If you've explicitly defined _DEBUG, you can screw-up this mechanism.

Normally, _DEBUG is implicitly defined by the compiler when you use one of the /M options on the compiler command-line or when you select a runtime library in the "C/C++" tab of the "Project Settings" dialog.

If you've somehow linked both debug and non-debug C runtimes into your application, you're very likely causing the assertion by allocating some memory with the non-debug runtimes and freeing it with the release runtimes (or vice-versa).

.B ekiM


0
 
mikeblasCommented:
The #ifdef's around redefinitions of new in your own source code are inconsequential.

MFC defines DEBUG_NEW to point at the debugging operator new only if _DEBUG is defined, and points at regular operator new if _DEBUG isn't defined.

.B ekiM

0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now