Date: Thu, 21 Oct 1999 14:08:00 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Peter J. Farley III" 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: 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 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.