www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/06/01/11:48:42

From: Andrew Crabtree <andrewc AT typhoon DOT rose DOT hp DOT com>
Message-Id: <199706011545.AA140769943@typhoon.rose.hp.com>
Subject: Re: One for the Gurus
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 01 Jun 1997 8:45:43 PDT
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.970601163236.24382A-100000@is>; from "Eli Zaretskii" at Jun 1, 97 4:33 pm

> > edx=3a633d52 
> You don't need to reproduce the problem under GDB to know where does
> it crash.  Just load the program and disassemble near the address
> where it crashes, like so:
> 
> 	gdb hello
> 	(gdb) disassemble 0x3424
> 
> GDB will list the function, if any, that includes the given address.
> You can then look at the source of the function that bombs and debug
> further.

I came up with something similar after I posted.  I loaded things
into gdb and then put a breakpoint right before Offending instruction.
It is located in malloc (one that I haven't touched), on a line like
follows 

movl (%edx),%eax

The crash shows it with a rediculously high edx, inside gdb
it is much more reasonable (about 0x4000)

I still don't understand why bash works but command.com doesn't.  
I assume (probably incorrectly) that they exec programs in the same way.

I think I will have to start replacing packages one by one and then
going back and overwriting.

Thanks

Andrew


- Raw text -


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