Debug Assertion Failed. dbgheap.c.line:1017

S.A.C. Madrid -- sacmad2@ibm.net
Friday, September 20, 1996

Environment: VC++ 4.0,  NT 3.51

Debug Assertion Failed
File:dbgheap.c
Line: 1017
Expresion:_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

Problem:
When I close my application document while debuging, the above error takes 
palce.
This bug is reported  at MSDN with ID:Q142385.
Solution that MSDN gives: Not use += CString operator, but I am not using it.
My problem is that I can't debug properly my program.
Any known patch for this bug at Internet site?
Any other solution?
(DON'T ANSWER BUY A NEW VERSION OF VC++, PLEASE)
Thanks for any sugestion.
Pedro: sacmad2@ibm.net 

---

Geoffrey Nicholls -- geoff@gazelle.com
Sunday, September 22, 1996

[Mini-digest: 2 responses]

I had this problem too. I was setting a base class string pointer variable
to a string constant. The base class assumed that the pointer was a heap
allocated pointer, and called free().

I originally had the following code in my CWinApp::InitInstance code:

#define APP_REGSTR_PROGRAM "gazelle"

BOOL DWinApp::InitInstance( ) 
{
    ...
    // registration stuff
    SetRegistryKey( APP_REGSTR_COMPANY );
    m_pszProfileName = APP_REGSTR_PROGRAM;
    ...
}

I changed it to read:

BOOL DWinApp::InitInstance( ) 
{
    ...
    // registration stuff
    SetRegistryKey( APP_REGSTR_COMPANY );
    free( (void *) m_pszProfileName );
    m_pszProfileName = _tcsdup( APP_REGSTR_PROGRAM );
    ...
}

_tcsdup() creates a copy of a string on the heap. This pointer gets freed at
program exit.

>Debug Assertion Failed
>File:dbgheap.c
>Line: 1017
>Expresion:_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

>Problem:
>When I close my application document while debuging, the above error takes 
>palce.
>This bug is reported  at MSDN with ID:Q142385.
>Solution that MSDN gives: Not use += CString operator, but I am not using it.
>My problem is that I can't debug properly my program.
>Any known patch for this bug at Internet site?
>Any other solution?

--------------------------------------
Geoffrey Nicholls
Gazelle Software
415/323-5545 (voice)
415/323-1913 (fax)
http://www.gazelle.com
667 Marion Ave
Palo Alto, CA, 94301
--------------------------------------

-----From: JLangseth1@aol.com

> ..._BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

I believe I have had this ASSERT fail (or one similar to it) in cases where I
either
"delete"d some memory twice, or the memory had become corrupted (by my code).
When memory is allocated there is some header info that the compiler stores
preceding the pointer you get.  I think I have seen where this header can be
corrupted by a bug in my code resulting in ASSERT failure (that's what they
are
for!).

I suggest that you determine what memory exactly is being handled when this
ASSERT fails; this may be obvious from the call stack.

If your memory is being corrupted, then it is likely a serious bug and should
be
fixed.  These types of problems have proven challenging at times to fix,
although the
compiler does provide mechanisms to find it if you are creative (eg. the
request
number that the debugger increments each time you get memory.)  I have
wondered
if a tool such as BoundsCheck (sp?) from Numega would be helpful and easy to
use
for this type of thing, but have not had a chance to try it.  I would like to
hear
from anyone with experience with these tools.

In summary, there is good chance that your ASSERT failure is not a compiler
bug but (fortunately, in my opinion) a bug in your code relating the a
misplaced
pointer.

Hope this helps.

---

| Вернуться в корень Архива |