Date: Tue, 15 Jun 1999 09:44:28 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: north AT iname DOT com
cc: djgpp AT delorie DOT com
Subject: Re: What about the registers????
In-Reply-To: <7k2bfp$j7d$1@nnrp1.deja.com>
Message-ID: <Pine.SUN.3.91.990615094408.2646D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 14 Jun 1999 north AT iname DOT com wrote:

> While taking your advice and debugged whith a couple of printf's and
> using the stack window in Rhide I found that the GPF was caused by
> a cfree(*pointer)-function.
> 
> 'call frame traceback
>  in function free+275
>  in function cfree+12

This usually means that your program overwrites some buffer allocated
from malloc/calloc.  malloc and free maintain some crucial information
about the memory pool as hidden pointers immediately before the
address they return to you; if you overwrite that information, free
will blow up.

> This program was linked with the libc-library ditrubuted in djdev202.
> So i blew the dust of from the old libc-library found in djdev201 and
> linked it with the program, and now it works without any GPF's

The version of malloc from v2.01 was much more forgiving to
programmatic errors like the one I described above, because it usually
had a large unused space beyond the end of the buffer that you
requested.  So overwriting the end of the buffer would usually go
unnoticed.  v2.02 removed the slack space, so it could use memory more
efficiently, and all those bugs suddenly raised their ugly heads.

So linking your program with v2.01 would be sweeping the problem under
the carpet instead of solving it.

I suggest to look carefuly at your code for some fragment that writes
beyond the limits of an allocated buffer.  If the crash happens at a
constant address, and if the data in the registers at the point of
crash is the same each time it crashes, the best way to hunt down this
problem is to put a data-write breakpoint (a.k.a. watchpoint) at the
address which causes the crash, and then when your program overwrites
that address, the debugger will catch it red-handed.

Note that, to use the above technique, you need to find out the *data*
address which causes the crash, not the EIP where it crashes.  Section
12.2 of the FAQ should explain how to find the faulty address (it
should be in one of the registers printed when it crashes;
disassemblying near the EIP where it crashes will tell you which
register is that, and the FAQ explains how to find this out).