Re: Can I Increase size of nNoMansLandSize?

One thing I do is put into my CWinApp-derived class an OnIdle handler

long CMyApp::OnIdle(int count)
{
ASSERT(_heapchk() == _HEAPOK);
return CWinApp::OnIdle(count);
}

That's my first and best step for looking for heap damage; it isolates it to which event
is responsible. Next, I start adding that ASSERT in other places in the sequence between
where it was OK and where it failed.
joe


On Wed, 16 Jan 2008 11:23:48 -0700, "Chris Shearer Cooper" <chris_web@xxxxxxx> wrote:

It's not writing to address 0x00000001, it's writing the DWORD value
0x00000001 to a random address.

The way I know, is that I will get an MFC error "heap corruption" and when I
look at memory, I see that in the "no man's land" that the debug memory
allocation creates, one of the DWORDs has been changed to 0x0000001.

Or, sometimes, I get a weird error because a pointer is all screwy, and when
I look, the pointer has been changed from a reasonable value to 0x00000001.

"AliR (VC++ MVP)" <AliR@xxxxxxxxxxxxx> wrote in message
news:3iqjj.33373$4V6.17121@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
If your program tries to write to address 0x00000001 VStudio will stop the
program at the line when that happens, if you are running it in the
debugger.

How do you know that it is writing to 0x00000001?

AliR.

"Chris Shearer Cooper" <chris_web@xxxxxxx> wrote in message
news:13osb6htofdcg4f@xxxxxxxxxxxxxxxxxxxxx
I run in debug mode nearly all the time, so that's when I see it, but I'm
thinking that if this happens in release mode too, we wouldn't know ... it
would show up as some random crash for an unknown reason, or an unexpected
data corruption, something like that ...



"AliR (VC++ MVP)" <AliR@xxxxxxxxxxxxx> wrote in message
news:URpjj.33366$4V6.9143@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Does this only happen in Release mode?

AliR.


"Chris Shearer Cooper" <chris_web@xxxxxxx> wrote in message
news:13oqkn42often9a@xxxxxxxxxxxxxxxxxxxxx
My application, for some reason, is writing a single DWORD into a
random location in its memory (the value is always 0x00000001), and I'm
trying to find out where!

I can't find any rhyme or reason to when this happens, so right now the
best I can do is stick a bunch of calls to _CrtCheckMemory() all over
the program and hope that the corruption will (1) hit a memory block in
a way that _CrtCheckMemory() can see it, and (2) that I will eventually
be able to narrow down _when_ this is happening.

But I had a thought. If I could tap into the MFC debug allocation
scheme, and increase the size of nNoMansLandSize, then the chance of
the bug hitting an area of memory that I could detect would increase
greatly!

But there doesn't seem to be any way to do this, outside of rebuilding
the MFC libraries, which I guess is a possibility, but not one I'm
looking forward to.

I can't find any other way to tap into the new/debug scheme. I tried
overriding new and delete, but got a bunch of "symbol already defined"
errors. I was thinking if I could tap into that, I could just increase
the size of every allocation (so if the caller wanted 4 bytes, I'd
actually allocate 40 and fill the extra 36 in with something I could
check later).

Any suggestions as to the least painful way to track down this problem?

Thanks!
Chris









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

Relevant Pages

  • Re: Freeing memory - will it be available immediately
    ... Your interpretation of "as the standard defines it" is ... Your interpretation of "for further allocation" as "for futher ... Except that this ignores the very reason for the standard, ... return the memory back to the OS in the manner you describe. ...
    (comp.lang.c)
  • Re: Can I Increase size of nNoMansLandSize?
    ... program and hope that the corruption will hit a memory block in a way ... If I could tap into the MFC debug allocation ... I can't find any other way to tap into the new/debug scheme. ...
    (microsoft.public.vc.mfc)
  • Re: Can I Increase size of nNoMansLandSize?
    ... location in its memory, ... If I could tap into the MFC debug allocation ... I can't find any other way to tap into the new/debug scheme. ...
    (microsoft.public.vc.mfc)
  • Re: Need help with "Fatal Execution Engine Error"
    ... They're should be no reason why an allocation should fail. ... reason why a failure to commit memory should occur). ... TotSize PctPctUsage ...
    (microsoft.public.dotnet.framework.clr)
  • Re: memory allocation/deallocation problem
    ... > seems to be going through the deallocation loop just fine. ... > interesting thing I just noticed is that if the memory requirements ... It is this huge 1.5 Gb chunk that for some reason ... to just the allocation and deallocation code? ...
    (comp.lang.c)