Mail Archives: djgpp/2000/04/19/03:56:12

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: <>
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 -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019