Wierd Error: Crashing in Debug Build, Works fine in Release

Discussion:

(too old to reply)

Jon

2006-08-17 08:04:26 UTC

Anyone know what could be the problem with my mfc app? If I were to
build my application in the Debug Build, and when the application
starts, the code hits an assertion in "heap_debug_malloc" and the code
crashes.

Is there two different heaps? One for release and one for debug? and
what is the difference?

When I run my code in release build, it works fine.

Would anyone have any ideas on what could possibly be wrong?

Thanks in advance.

nightcrawler

2006-08-17 08:15:16 UTC

Permalink

As far as I know if you get any problem in debug build and application
runs fine in release build then from my experience (I have faced same
problem)I can tell that your coding/programming style is not a standard
one. You need to change ur coding habits a bit. I say this because I
had faced same problems earlier. And yes..test your program which are
in development in Debug Build only.

Oleg Starodumov

2006-08-17 10:30:03 UTC

Permalink

What kind of assertion? What file/line? What functions are on the call stack?

Usually such assertions mean heap corruption or a kind of heap misuse
that can lead to heap corruption.

Post by Jon
Is there two different heaps? One for release and one for debug? and
what is the difference?

There is more than two heaps :)

Release and debug versions of CRT library use different heaps (debug version
provides additional error checking).

In modern versions of Windows OS, both these heaps are implemented
on top of Win32 heap (provided by the OS). From debugging point of view,
Win32 heap can function in several modes:
- "Normal" heap - used when the application is running normally (not started under debugger)
- Debug Win32 heap - used if the application has been started under debugger
- Normal/Light PageHeap - used if configured in Registry for this application
- Full PageHeap - used if configured in Registry for this application

"Normal" heap does not provide any debugging checks, while other heaps do.

Debug Win32 heap and Normal/Light PageHeap are similar and provide
moderate debugging capabilities (usually not too effective) which are mostly
based on introducing additional padding around allocated heap blocks,
which are checked at some periods of time to detect overwrites. As a result,
the memory layout of the heap is very different from the "normal" case,
which can expose some bugs and hide some others. (Btw, the same applies
to the debug checks performed by debug version of CRT library, since it
also uses similar approach to detect heap corruption)

Full PageHeap uses another approach to error detection, and it is usually very effective
in detecting various kinds of heap corruption, but causes extensive memory usage
(not a problem for most apps).

If your application raises an assertion in a CRT heap function, you should usually
try to determine the reason of the assertion (what kind of information it was checking -
it will tell you what kind of data has been corrupted).

If the reason of the assertion is not obvious, it makes sense to enable Full PageHeap
and test your application with it, as described here:
http://www.debuginfo.com/tips/userbpntdll.html

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

lauhw2000

2006-08-17 14:29:34 UTC

Permalink

Is it possible to paste your code that causes the crash?

Jon

2006-08-17 21:03:27 UTC

Permalink

Thanks for all the replies... actually, the code that crashes is not
apart of my code. The actual call that crashes is in dbgheap.c which
is apart of msvc.

its in the function: "void * __cdecl _heap_alloc_dbg(..)" and the
assertion that goes off is this code:

/* break into debugger at specific memory allocation */
if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)
_CrtDbgBreak();

/* forced failure */
if (!(*_pfnAllocHook)(_HOOK_ALLOC, NULL, nSize, nBlockUse,
lRequest, szFileName, nLine))
{
if (szFileName)
_RPT2(_CRT_WARN, "Client hook allocation failure at
file %hs line %d.\n",
szFileName, nLine);
else
_RPT0(_CRT_WARN, "Client hook allocation failure.\n");

return NULL;
}

As for the call stack, I have no idea what this means.. but if you
look at towards the top, there is a call to
msvcr71d.dll!_heap_alloc_dbg(...) that is the call that is asserting
my error... Thanks

////////////////////////////////////////////
// Call stack
///////////////////////////////////////////

MyTestProg.exe!0045600f()
MyTestProg.exe!0046c52b()
MyTestProg.exe!00474c63()
user32.dll!77d5cd87()
MyTestProg.exe!0047e878()
MyTestProg.exe!0047e319()
user32.dll!77d4c00e()
msvcr71d.dll!_heap_alloc_dbg(unsigned int nSize=0x00325f38, int
nBlockUse=0x0012ef80, const char * szFileName=0x0012f3cc, int
nLine=0x00000000) Line 359 + 0x1e C
MyTestProg.exe!0047def9()
msvcr71d.dll!_nh_malloc_dbg(unsigned int nSize=0x00325f40, int
nhFlag=0x0012edd8, int nBlockUse=0x0012ef90, const char *
szFileName=0x00508680, int nLine=0xffffffff) Line 267 + 0x7 C
msvcr71d.dll!_malloc_dbg(unsigned int nSize=0x00000000, int
nBlockUse=0x00000000, const char * szFileName=0x00325f40, int
nLine=0x0012fc74) Line 176 + 0x1b C
MyTestProg.exe!0047e055()
MyTestProg.exe!0047d795()
mfc71ud.dll!ATL::CSimpleStringT<wchar_t,1>::Attach(ATL::CStringData *
pData=0x0012ef80) Line 712 + 0x8 C++
mfc71ud.dll!ATL::CSimpleStringT<wchar_t,1>::~CSimpleStringT<wchar_t,1>()
Line 265 C++
mfc71ud.dll!ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t>

::~CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >() Line 963 + 0x8 C++

MyTestProg.exe!00471095()
mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x0012ef80, unsigned int
nMsg=0x0012ef9c, unsigned int wParam=0x0047c08d, long
lParam=0x0012f3cc) Line 209 + 0x27 C++
MyTestProg.exe!0047beb1()
user32.dll!77d487ff()
MyTestProg.exe!0047c6e0()
MyTestProg.exe!004a8d7c()
MyTestProg.exe!004a8d8c()
MyTestProg.exe!004a78d3()
MyTestProg.exe!004a7915()
MyTestProg.exe!004a6e78()
MyTestProg.exe!004a6e9a()
MyTestProg.exe!0046ffc1()
user32.dll!77d4b7ab()
mfc71ud.dll!CComboBox::GetItemData(int nIndex=0x0012f3cc) Line 743 +
0x44 C++
MyTestProg.exe!00473688()
mfc71ud.dll!CHandleMap::LookupPermanent(void * h=0x000400f6) Line 116
+ 0x16 C++
mfc71ud.dll!CWnd::AssertValid() Line 888 + 0xf C++
mfc71ud.dll!CDialog::AssertValid() Line 780 C++
mfc71ud.dll!AfxAssertValidObject(const CObject * pOb=0x00000001, const
char * lpszFileName=0x0012f148, int nLine=0x7c34d5dc) Line 104 C++
MyTestProg.exe!00507fe3()
mfc71ud.dll!ATL::CTraceFileAndLineInfo::operator()(unsigned long
dwCategory=0x000003e8, unsigned int nLevel=0x00000000, const char *
pszFmt=0x00457d7e, ...) Line 163 + 0x27 C++
mfc71ud.dll!CCmdTarget::OnCmdMsg(unsigned int nID=0x000003e8, int
nCode=0x00000000, void * pExtra=0x00000000, AFX_CMDHANDLERINFO *
pHandlerInfo=0x00000000) Line 396 + 0x27 C++
mfc71ud.dll!CDialog::OnCmdMsg(unsigned int nID=0x000003e8, int
nCode=0x00000000, void * pExtra=0x00000000, AFX_CMDHANDLERINFO *
pHandlerInfo=0x00000000) Line 88 + 0x18 C++
mfc71ud.dll!CWnd::OnCommand(unsigned int wParam=0x000003e8, long
lParam=0x000400dc) Line 2550 C++
mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=0x00000111, unsigned
int wParam=0x000003e8, long lParam=0x000400dc, long *
pResult=0x0012f368) Line 1759 + 0x1c C++
mfc71ud.dll!CWnd::WindowProc(unsigned int message=0x00000111, unsigned
int wParam=0x000003e8, long lParam=0x000400dc) Line 1745 + 0x1e C++
mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x0012fbf4, HWND__ *
hWnd=0x000400f6, unsigned int nMsg=0x00000111, unsigned int
wParam=0x000003e8, long lParam=0x000400dc) Line 241 + 0x1a C++
mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x000400f6, unsigned int
nMsg=0x00000111, unsigned int wParam=0x000003e8, long
lParam=0x000400dc) Line 389 C++
mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x000400f6, unsigned int
nMsg=0x00000111, unsigned int wParam=0x000003e8, long
lParam=0x000400dc) Line 209 + 0x15 C++
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d4b368()
user32.dll!77d70494()
user32.dll!77d4b743()
user32.dll!77d4b7ab()
user32.dll!77d7fc9d()
user32.dll!77d76530()
user32.dll!77d58386()
mfc71ud.dll!CThreadLocal<AFX_MODULE_THREAD_STATE>::GetData() Line 177
+ 0xd C++
mfc71ud.dll!AfxGetThread() Line 142 + 0x5 C++
mfc71ud.dll!AfxGetMainWnd() Line 36 + 0x11 C++
mfc71ud.dll!CWinThread::ProcessMessageFilter(int code=0x000400dc,
tagMSG * lpMsg=0x00000202) Line 872 + 0x5 C++
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d4ecd2()
user32.dll!77d70494()
user32.dll!77d489a5()
user32.dll!77d553a0()
user32.dll!77d70494()
user32.dll!77d489e8()
user32.dll!77d6e819()
mfc71ud.dll!CWnd::IsDialogMessageW(tagMSG * lpMsg=0x001445f8) Line
200 C++
mfc71ud.dll!CWnd::PreTranslateInput(tagMSG * lpMsg=0x001445f8) Line
4512 C++
mfc71ud.dll!CDialog::PreTranslateMessage(tagMSG * pMsg=0x001445f8)
Line 83 C++
fc71ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x000400f6,
tagMSG * pMsg=0x001445f8) Line 3129 + 0x12 C++
mfc71ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x001445f8)
Line 238 + 0x12 C++
mfc71ud.dll!CWinThread::PreTranslateMessage(tagMSG * pMsg=0x001445f8)
Line 795 + 0x9 C++
mfc71ud.dll!AfxPreTranslateMessage(tagMSG * pMsg=0x001445f8) Line 257
+ 0xf C++
mfc71ud.dll!AfxInternalPumpMessage() Line 183 + 0x18 C++
mfc71ud.dll!CWinThread::PumpMessage() Line 916 C++
mfc71ud.dll!AfxPumpMessage() Line 195 + 0xb C++
mfc71ud.dll!CWnd::RunModalLoop(unsigned long dwFlags=0x00000004) Line
4566 + 0x5 C++
mfc71ud.dll!CDialog::DoModal() Line 527 + 0xc C++
MyTestProg.exe!004703dc()
ole32.dll!774f43e3()
MyTestProg.exe!00470245()
ntdll.dll!***@0() + 0x8b
ntdll.dll!***@8() + 0x5f
ntdll.dll!***@20() - 0x29

Paul Barrett

2006-08-17 21:53:54 UTC

Permalink

Usually when I see this it's because not everything you're linking was built
with the same heap - i.e. some components were built as Release and some as
Debug.
Make sure all the libraries you're linking in are part of your workspace
then try doing a Rebuild All.

Post by Jon
Thanks for all the replies... actually, the code that crashes is not
apart of my code. The actual call that crashes is in dbgheap.c which
is apart of msvc.
its in the function: "void * __cdecl _heap_alloc_dbg(..)" and the
/* break into debugger at specific memory allocation */
if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)
_CrtDbgBreak();
/* forced failure */
if (!(*_pfnAllocHook)(_HOOK_ALLOC, NULL, nSize, nBlockUse,
lRequest, szFileName, nLine))
{
if (szFileName)
_RPT2(_CRT_WARN, "Client hook allocation failure at
file %hs line %d.\n",
szFileName, nLine);
else
_RPT0(_CRT_WARN, "Client hook allocation failure.\n");
return NULL;
}
As for the call stack, I have no idea what this means.. but if you
look at towards the top, there is a call to
msvcr71d.dll!_heap_alloc_dbg(...) that is the call that is asserting
my error... Thanks
////////////////////////////////////////////
// Call stack
///////////////////////////////////////////
MyTestProg.exe!0045600f()
MyTestProg.exe!0046c52b()
MyTestProg.exe!00474c63()
user32.dll!77d5cd87()
MyTestProg.exe!0047e878()
MyTestProg.exe!0047e319()
user32.dll!77d4c00e()
msvcr71d.dll!_heap_alloc_dbg(unsigned int nSize=0x00325f38, int
nBlockUse=0x0012ef80, const char * szFileName=0x0012f3cc, int
nLine=0x00000000) Line 359 + 0x1e C
MyTestProg.exe!0047def9()
msvcr71d.dll!_nh_malloc_dbg(unsigned int nSize=0x00325f40, int
nhFlag=0x0012edd8, int nBlockUse=0x0012ef90, const char *
szFileName=0x00508680, int nLine=0xffffffff) Line 267 + 0x7 C
msvcr71d.dll!_malloc_dbg(unsigned int nSize=0x00000000, int
nBlockUse=0x00000000, const char * szFileName=0x00325f40, int
nLine=0x0012fc74) Line 176 + 0x1b C
MyTestProg.exe!0047e055()
MyTestProg.exe!0047d795()
mfc71ud.dll!ATL::CSimpleStringT<wchar_t,1>::Attach(ATL::CStringData *
pData=0x0012ef80) Line 712 + 0x8 C++
mfc71ud.dll!ATL::CSimpleStringT<wchar_t,1>::~CSimpleStringT<wchar_t,1>()
Line 265 C++
mfc71ud.dll!ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t>

::~CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> >

() Line 963 + 0x8 C++

Joseph M. Newcomer

2006-08-18 01:54:53 UTC

Permalink

This is still not informative. Please stop using the word "crash", since there is no
evidence that you are crashing, only that you are taking assertion failures. The code
that DETECTS the crash is in heap_alloc_debug; the code that CAUSES THE ERROR IT DETECTS
is in your code. So first, the question is, "what was your code doing at the time it
called _heap_alloc_dbg?". But this is only part of the problem. What is most likely
wrong is that you have damaged the heap, but it is hard to tell because you did not
actually say WHICH of those lines was actually involved in the crash. And you did not
indicate, had you actually told us the line, what the *values* were of any of the
variables.

It smells like a heap damage bug caused by a memory overwrite. Generally, given the
nature of your question, that is quite possibly the most likely cause of your error. So
make sure you have properly allocated every 'new' to be the correct length and you don't
exceed the length.

Telling us what is on the top of the stack is pretty useless. We knew that. From the
backtrace I'm seeing, it is trying to allocate a string, which usually poses no problem,
so again itis most likely you've just overwritten memory somewhere else. The stack itself
seems to be a bit strange as well, because it has lots of hex addresses but very few
symbolic names. Are you doing something strange about symbol tables here?

One way to deal with this is to liberally sprinkle
ASSERT(_heapchk() == _HEAPOK)
statements in your code near places you are doing things with arrays of data you've
allocated, and override the OnIdle handler of your CWinApp class and toss one in there.

This invokes the same checking that caught you in the allocator and helps pin down who
really made the error.
joe

::~CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >() Line 963 + 0x8 C++

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer

2006-08-19 00:42:00 UTC

Permalink

See my new essay on heap damage detection

http://www.flounder.com/memory_damage.htm

Post by Joseph M. Newcomer
This is still not informative. Please stop using the word "crash", since there is no
evidence that you are crashing, only that you are taking assertion failures. The code
that DETECTS the crash is in heap_alloc_debug; the code that CAUSES THE ERROR IT DETECTS
is in your code. So first, the question is, "what was your code doing at the time it
called _heap_alloc_dbg?". But this is only part of the problem. What is most likely
wrong is that you have damaged the heap, but it is hard to tell because you did not
actually say WHICH of those lines was actually involved in the crash. And you did not
indicate, had you actually told us the line, what the *values* were of any of the
variables.
It smells like a heap damage bug caused by a memory overwrite. Generally, given the
nature of your question, that is quite possibly the most likely cause of your error. So
make sure you have properly allocated every 'new' to be the correct length and you don't
exceed the length.
Telling us what is on the top of the stack is pretty useless. We knew that. From the
backtrace I'm seeing, it is trying to allocate a string, which usually poses no problem,
so again itis most likely you've just overwritten memory somewhere else. The stack itself
seems to be a bit strange as well, because it has lots of hex addresses but very few
symbolic names. Are you doing something strange about symbol tables here?
One way to deal with this is to liberally sprinkle
ASSERT(_heapchk() == _HEAPOK)
statements in your code near places you are doing things with arrays of data you've
allocated, and override the OnIdle handler of your CWinApp class and toss one in there.
This invokes the same checking that caught you in the allocator and helps pin down who
really made the error.
joe

::~CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >() Line 963 + 0x8 C++

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Oleg Starodumov

2006-08-18 08:00:42 UTC

Permalink

Post by Jon
As for the call stack, I have no idea what this means.. but if you
look at towards the top, there is a call to
msvcr71d.dll!_heap_alloc_dbg(...) that is the call that is asserting
my error... Thanks

It looks like the call stack was taken at the moment when the application crashed,
not at the moment of the assertion. Right? (To get the call stack at the moment
of the assertion, press Retry in the assertion dialog)

Anyway, the only two places that can assert inside _heap_alloc_dbg before the line
mentioned in the call stack are at lines 346 and 356 (the latter is not an assertion, in fact,
but a hard-coded breakpoint).
(Please correct me if the assertion happens at some other line)

If the code asserts at line 346, you have a heap corruption. A simple and effective
way to detect who corrupts the heap is to enable Full PageHeap for this application
(see the link in my previous reply for how-to information).

If the break occurs at line 356, it would be interesting to know the values reported
when you enter the following into Watch window (when the app is stopped in
the debugger right after the break):

{,,msvcr71d.dll}_crtBreakAlloc
{,,msvcr71d.dll}_lRequestCurr

Oleg

Joseph M. Newcomer

2006-08-18 00:56:17 UTC

Permalink

The code that actually did the damage might be billions of instructions before the code
that detected it.
joe

Post by lauhw2000
Is it possible to paste your code that causes the crash?

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Jim Langston

2006-08-17 23:58:27 UTC

Permalink

Post by Jon
Anyone know what could be the problem with my mfc app? If I were to
build my application in the Debug Build, and when the application
starts, the code hits an assertion in "heap_debug_malloc" and the code
crashes.
Is there two different heaps? One for release and one for debug? and
what is the difference?
When I run my code in release build, it works fine.
Would anyone have any ideas on what could possibly be wrong?
Thanks in advance.

There are a few things that can programs to crash in one of debug or release
but not the other. A common problem is variable initialization. In debug
variables are initialized to 0. Not in release.

The other has to do with array/variable overflows. It is very possible to
overflow an array or variable yet have your program run to completion
without an error. Just because you didn't happen to use the memory that got
overflowed in anything that would cause an error. But debug and release
mode seem to place their variables in memory a little differently, so if it
crashes in one but not the other, you should also look at array/varialbe
overlows.

An array overflow:

int MyArray[5];
for ( int i = 1; i <= 5; ++i )
MyArray[i] = i;

That would cause MyArray[i] to try to access MyArray[5] which isn't a part
of the array. Arrays are 0 bound so would go from [0] to [4].

Variable overflow (not as common and usually have to do with throwing
pointers around):

short int MyInt;

void* MyPointer = &MyInt; (( might need (void*) &MyInt here ))
...
int* MyIntP = (int*) MyPointer;
*MyPointer = 100000;

Basically through pointers we wrote an int to a short int writing to memory
that doesn't belong to the short int.

Joseph M. Newcomer

2006-08-18 02:01:30 UTC

Permalink

See below...

Post by Jim Langston

There are a few things that can programs to crash in one of debug or release
but not the other. A common problem is variable initialization. In debug
variables are initialized to 0. Not in release.

****
No. Not in either. In debug mode, local variables are initialized to 0xCCCCCCCC. In
release mode they are not initialized. Newly allocated heap storage is initialized to
0xCDCDCDCD. Freed heap storage is cleared to 0xDFDFDFDF [or something like that]. These
do not happen in release mode, so in release mode you have the illusion things are working
when in fact they are busily screwing you over.

Never, ever, say "It works in release and crashes in debug, what's wrong with debug mode."
What's wrong is your program is simply WRONG, and you have to fix it, and that's what
debug mode is all about: trying to find errors in a meaningful fashion instead of just
letting random damage happen.

There are interesting situations in which code that appears to work correctly in debug
mode fails in release mode; I've documented a number of these in my essay on "Surviving
the release bulid" on my MVP Tips site. Many of these are bugs which actually sneak
through the extensive checks of debug builds, but show up in release mode; they're still
bugs in your code.

But you have a different problem: you have something that fails in debug mode. You have
to fix it and make sure it works PERFECTLY in debug mode before even CONSIDERING THE
POSSIBILITY of building a release mode version. If it doesn't work in debug mode, it's
broken, and any release mode behavior is not even worth discussing.
*****

Post by Jim Langston
The other has to do with array/variable overflows. It is very possible to
overflow an array or variable yet have your program run to completion
without an error. Just because you didn't happen to use the memory that got
overflowed in anything that would cause an error. But debug and release
mode seem to place their variables in memory a little differently, so if it
crashes in one but not the other, you should also look at array/varialbe
overlows.

*****
This is probably the error, with 99% confidence.
*****

Post by Jim Langston
int MyArray[5];
for ( int i = 1; i <= 5; ++i )
MyArray[i] = i;
That would cause MyArray[i] to try to access MyArray[5] which isn't a part
of the array. Arrays are 0 bound so would go from [0] to [4].
Variable overflow (not as common and usually have to do with throwing
short int MyInt;
void* MyPointer = &MyInt; (( might need (void*) &MyInt here ))
...
int* MyIntP = (int*) MyPointer;
*MyPointer = 100000;
Basically through pointers we wrote an int to a short int writing to memory
that doesn't belong to the short int.

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

lauhw2000

2006-08-18 06:41:19 UTC

Permalink

I have the same problem before. My program crash in the Debug mode.
After a few months in finding the reasons why crash in Debug mode but
not in Release mode, I found out that either the variables were not
init or pointer has been deleted somewhere. The problem will be
augmented in multi-threaded app..... local variable will be out of
scope.

I suggest that you use the call stack to trace your last code before
jump into MSVC source. Watch the address of the pointer or even use the
TRACE() to see what is the value in the variable.

unknown

2006-08-18 13:31:52 UTC

Permalink

Post by Joseph M. Newcomer
Freed heap storage is cleared to 0xDFDFDFDF [or something like that]. These
do not happen in release mode, so in release mode you have the illusion things are working
when in fact they are busily screwing you over.

I think its 0xDD for freed memory and 0xFD for guard bytes, when using
the debug deallocator and allocator respectively. But that's from
memory.

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jon

2006-08-18 19:03:52 UTC

Permalink

Thank you guys for everything, its been a lot of help. I tried looking
over my code for any memory problems, and I couldn't find any. In
fact, throughout the applciation, I don't allocate anything on the heap
explicitely ( i.e use new/free etc.). I checked all my arrays to make
sure I am not doing any buffer overruns as well.

I do pass a lot of variables though as reference. Maybe this could be
a problem?

I investigated the error in a bit more detail, so in dbgheap.c, when I
try to debug my application, it actually stops at line 359 with an
unhandled exception error:

the actual error is:

"Unhandled exception at 0x0045600f in MyTestProg.exe: 0xC0000096:
Privileged instruction."

I apologize, but thought it was an assertion failure. Due to my lack
of experience using the VS debugger, I assumed that when my code
stopped at the ASSERT statement, than that was the problem. Sorry about
that.

What is wierd, is in call stack, at the very top, it shows that my code
is at the top, but when I click on it to see the exact location, it
tells me that it wants to show me the assembly code. I am assuming
though that since I built this with Visual Studio, and I have all the
symbols and the source, that I should just be able to see the source
code... wierd.. huh?

Thanks again for the replies.

Joseph M. Newcomer

2006-08-20 23:57:22 UTC

Permalink

Note that there are a lot of implicit allocations. Every CString. Every CArray, CList,
or CMap. All the flavors of CArray, such as CDWordArray, CObArray, etc. There are tons
of implicit allocations going on all the time within MFC.

Well, what else do you know about it? For example, if it stops on the assert, it might be
because you've really trashed memory badly.

Passing "by reference" means using the & designator in a parameter list; passing by
pointer means you use the * designator. Which are you using? If you pass a pointer to a
character buffer (such as a stack local) and overrun it, all bets are off as to the
integrity of ANY part of the rest of your code from that point on, and heap damage is
probably one of the many possible outcomes. If you pass a pointer to anything with a
length, you had better not exceed that length.

check out my essay.
joe

Post by Jon
Thank you guys for everything, its been a lot of help. I tried looking
over my code for any memory problems, and I couldn't find any. In
fact, throughout the applciation, I don't allocate anything on the heap
explicitely ( i.e use new/free etc.). I checked all my arrays to make
sure I am not doing any buffer overruns as well.
I do pass a lot of variables though as reference. Maybe this could be
a problem?
I investigated the error in a bit more detail, so in dbgheap.c, when I
try to debug my application, it actually stops at line 359 with an
Privileged instruction."
I apologize, but thought it was an assertion failure. Due to my lack
of experience using the VS debugger, I assumed that when my code
stopped at the ASSERT statement, than that was the problem. Sorry about
that.
What is wierd, is in call stack, at the very top, it shows that my code
is at the top, but when I click on it to see the exact location, it
tells me that it wants to show me the assembly code. I am assuming
though that since I built this with Visual Studio, and I have all the
symbols and the source, that I should just be able to see the source
code... wierd.. huh?
Thanks again for the replies.

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer

2006-08-18 20:33:32 UTC

Permalink

I checked the dbgheap.c file in the CRT source:

static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */
static unsigned char _bDeadLandFill = 0xDD; /* fill free objects with this */
static unsigned char _bCleanLandFill = 0xCD; /* fill new objects with this */
static unsigned char _bAlignLandFill = 0xBD; /* fill no-man's land for
aligned routines */
so your memory was better than mine...
joe

Post by unknown

I think its 0xDD for freed memory and 0xFD for guard bytes, when using
the debug deallocator and allocator respectively. But that's from
memory.

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

unknown

2006-08-19 22:26:06 UTC

Permalink

Post by Joseph M. Newcomer
so your memory was better than mine...

So how come I can never remember what I did yesterday when I have to
fill in a timesheet? :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Joseph M. Newcomer

2006-08-20 00:58:52 UTC

Permalink

Conversation at our dinner table:

Me: "So how was work today?"
She: "I can't remember. That was far too long ago."
joe

Post by unknown

Post by Joseph M. Newcomer
so your memory was better than mine...

So how come I can never remember what I did yesterday when I have to
fill in a timesheet? :-)

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer

2006-08-18 00:55:02 UTC

Permalink

Well, it is doing exactly what it is *supposed* to be doing: it fails because you screwed
up the heap. In the release version, there is no checking for this, so what happens is
that at some indeterminate time in the future, you just crash with some access fault, or
worse still, don't crash but corrupt your data in some unpleasant way.

The debug heap is designed to catch a lot of common errors, such as freeing the same
location twice, freeing an address that is not obtained from new or malloc, clobbering
heap pointers by buffer overruns, etc.

What this means is (a) you have a serious bug and (b) you have to fix it.

Note that "the code crashes" is a meaningless statement. Assertion failures are not
"crashes", they are assertion failures. Access faults are one of the common consequences
of the kind of damage these assertion failures are reporting, but you have not actually
said what has happened.

Did you look at the code where it stops? It probably has some useful comment about what
went wrong. Also, note that assertion failures do not happen in "heap_debug_malloc". They
happen at a particular LINE in that function, and if you had bothered to tell us what that
line was (and what version of VS you're using) we could probably suggest what had gone
wrong.

First approximation: look for buffer overruns
Second approximation: look for using pointers after you've done free/delete

Note that you are living in a delusional world if you think your code "runs fine" in the
release version. The correct statement is "the damage that happens has not yet been
detected in the release version".
joe

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm