Date:	Wed, 19 Apr 2000 09:46:55 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"J.P. Morris" <doug-15 AT bigfoot DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: dead beef
In-Reply-To:	<38FC4A45.54C24CDF@bigfoot.com>
Message-ID:	<Pine.SUN.3.91.1000419094631.10023K@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 18 Apr 2000, J.P. Morris wrote:

> > I suggest using the _CRT0_FLAG_FILL_SBRK_MEMORY (not
> > _CRT0_FLAG_FILL_DEADBEEF!) to see whether this is your problem.
> 
> At one stage I tried this, but it crashed by NULL dereference
> instead.

This, in my opinion, is a clear indication that your program either
uses uninitialized pointers, or somehow overwrites pointers with data
from uninitialized buffers.

> Suppose I did this?
> 
> char array[128];
> 
> for(ctr=0;ctr<65535;ctr++)
>   array[ctr]=0;
> 
> Fortify (and presumably MSS et al) put sentry-blocks around memory that
> is allocated dynamically, using a wrapper around malloc() and calloc(),
> but since malloc and free aren't used for local arrays or other objects,
> it wouldn't detect that unless it was a big enough overrun to reach
> a dynamically-allocated object.

That's why I suggested to use watchpoints inside a debugger.  You can
put a watchpoint on one or more (up to 4) pointers that get corrupted,
and then the debugger will catch the code which does that, when it
does so.

- Raw text -