From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: dead beef
Date: 18 Apr 2000 14:34:31 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 35
Message-ID: <8dhrpn$q3s$1@nets3.rz.RWTH-Aachen.DE>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000418113426 DOT 28255U-100000 AT is> <38FC4A45 DOT 54C24CDF AT bigfoot DOT com>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 956068471 26748 137.226.32.75 (18 Apr 2000 14:34:31 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 18 Apr 2000 14:34:31 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

J.P. Morris <doug-15 AT bigfoot DOT com> wrote:
> Eli Zaretskii 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.

You should have tried that in a debugger, and checked where this NULL
pointer came from, to find the bug. 


[...]
> 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.

Right. To detect overruns or underruns in arrays not coming from
malloc() (i.e. automatic ones on the stack, or static ones), you need
other tools. You might want to try the GCC extension 'Checker-gcc',
for this. Unlike the usual malloc()-checkers, it can also check
non-malloc()ed storage. It will only work with Linux, not DJGPP,
though.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.