From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Debugger that can detect buffer overruns?
Date:	20 Nov 2000 13:08:13 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	39
Message-ID:	<8vb7nt$ltd$1@nets3.rz.RWTH-Aachen.DE>
References:	<8v3s96$ssh$1 AT nnrp1 DOT deja DOT com>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 974725693 22445 137.226.32.75 (20 Nov 2000 13:08:13 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	20 Nov 2000 13:08:13 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

dcasale AT my-deja DOT com wrote:
> I don't know.  Maybe I'm just having trouble understanding the GDB
> documentation.  Maybe it _does_ check for buffer overruns and I don't
> know how to use that feature.

GDB cannot really check for buffer overruns, simply because it doesn't
know about all possible buffers that exist in the program, or about
the places beyond their ends that are going to be overrun. 

Checking for buffer overruns requires instrumentation of the code
being produced by the C compiler.  GCC can add such instrumentation,
in it's more recent releases. There's an extension package to GCC
called 'checker' that makes use of that (and some other tricks) to
provide full-scale memory access checking, but that's not been ported
to DJGPP.  When I once had that one working on my Linux box, it proved
quite useful.  It warns about reading unitialized data values both on
the heap and the stack, about calling functions with illegal
arguments, and lots of other things. It also contains malloc()
debugging, but I have my doubts that your particular application is
really having its problems on the malloc() front.

For now, I usually bring my code to an Alpha box and use a tool
provided by Digital, called "third degree", that does this type of
memory access checking for me, and quite successfully, too.

> I just ran a test with my compression program (without using YAMD) to
> see whether it would always fail in exactly the same spot.  After
> failing with a "General Protection Error" on one particular delete, I
> ran the _exact same code_ again, after a system reboot, and it failed
> on a different delete.

That's almost certainly not originally a problem of buffer overrun,
then, but rather one of using uninitialized data. The 0xdeadbeef _crt0
option in DJGPP may help to more easily provoke one of those to show
up its ugly head.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -