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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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.