Date:	Thu, 21 Oct 1999 14:08:00 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: Are there any memory debuggers other than MSS and YAMD?
In-Reply-To:	<380e090b.11437752@news3.banet.net>
Message-ID:	<Pine.SUN.3.91.991021140743.2684P-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 20 Oct 1999, Peter J. Farley III wrote:

> I'm running DJGPP v2.02, gcc 2.8.1 (10-28-98), libc/libg/libm 11-15-98
> in a W95 DOS box, LFN=Y.

AFAIK, YAMD won't help you on Windows, since it uses several DPMI
functions for which you need CWSDPMI.  Can you try this in plain DOS
mode?

> Call frame traceback EIPs:
>   0x00024b90   _malloc+192

Crashes at malloc+192 are a tell-tale sign of a program that either
overruns an malloc'ed buffer, or calls free more than once with the
same pointer.

One possible approach to attack these problems goes like this:

  1. Disassemble the program at the top-most EIP that is printed in
     the traceback.  In this case, that's 0x24b90.  In gdb, the
     command is "x/i 0x24b90".

  2. Look at the instruction that crashed and the registers' dump
     printed when the program crashes, and find the register that
     holds the garbled value.  (In your case, it's probably EBX, but
     that's a guess; don't take it for granted.)

  3. Look at the source of malloc and find out what address stored the
     garbled value, by correlating the disassembled code and the
     source.

  4. Run the program under a debugger, put a watchpoint (a.k.a. data
     breakpoint) at the address which gets garbled, and see what code
     triggers the watchpoint.

The above assumes that (1) the registers' contents printed each time
the program crashes is identical, and (2) running the program under a
debugger doesn't make the crashes go away.

- Raw text -