Backtracing broken core dumps

Backtracing broken core dumps

[Catherine Smith]

I have attempted to find back traces of several core dumps
which have resulted from executing damaged pointers to
functions, or null pointers to functions.
Sometimes a gdb command of the form

   set pc=$lr

would help, except that gdb says

  (gdb) set pc=$lr
  You can't do that without a process to debug

I have to resort to careful editting of the core file with a binary editor.
This works, is useful, but isn't very friendly.

Similarly today I had a crash in an Arm assembler memcpy() .
Careful unwinding the stack by hand and editting the core dump
allowed a stack trace to be extracted.

Is there a gdb command which allows this sort of change?
If not, could one be created?

Thanks,
John Smith

Re: Backtracing broken core dumps

[Andreas Schwab]

"Catherine Smith" <Catherine.Smith@arrows.demon.co.uk> writes:

> I have attempted to find back traces of several core dumps
> which have resulted from executing damaged pointers to
> functions, or null pointers to functions.
> Sometimes a gdb command of the form
>
>   set pc=$lr
>
> would help, except that gdb says
>
>  (gdb) set pc=$lr
>  You can't do that without a process to debug

Try using the frame command, passing it the address of the frame you
want to examine.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Backtracing broken core dumps

[Thiago Jung Bauermann]

Em Domingo 19 Julho 2009 13:11:26 Andreas Schwab escreveu:
> "Catherine Smith" <Catherine.Smith@arrows.demon.co.uk> writes:
> > I have attempted to find back traces of several core dumps
> > which have resulted from executing damaged pointers to
> > functions, or null pointers to functions.
> > Sometimes a gdb command of the form
> >
> >   set pc=$lr
> >
> > would help, except that gdb says
> >
> >  (gdb) set pc=$lr
> >  You can't do that without a process to debug
>
> Try using the frame command, passing it the address of the frame you
> want to examine.

IIRC Ulrich Weigand considers that usage of the frame command to be 
deprecated... I don't know the rationale though.
-- 
[]'s
Thiago Jung Bauermann

Re: Backtracing broken core dumps

[Daniel Jacobowitz]

On Sun, Jul 19, 2009 at 05:03:46PM +0100, Catherine Smith wrote:
> Is there a gdb command which allows this sort of change?
> If not, could one be created?

We should just allow this; IMO it's a bug.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Backtracing broken core dumps

[Paul Koning]

Excerpt of message (sent 19 July 2009) by Andreas Schwab:
> "Catherine Smith" <Catherine.Smith@arrows.demon.co.uk> writes:
> 
> > I have attempted to find back traces of several core dumps
> > which have resulted from executing damaged pointers to
> > functions, or null pointers to functions.
> > Sometimes a gdb command of the form
> >
> >   set pc=$lr
> >
> > would help, except that gdb says
> >
> >  (gdb) set pc=$lr
> >  You can't do that without a process to debug
> 
> Try using the frame command, passing it the address of the frame you
> want to examine.

How does that work?  I see that option documented, but I can't see how
that would work.  At least not for MIPS, where you need to have a PC
in order to know how to display a frame.

I agree with Daniel, setting PC ought to just work.  (More precisely,
PC and SP, or whatever other registers are needed to walk the
callstack.)   This issue comes up every other month or so, and there
is no good answer at the moment.

   paul

Re: Backtracing broken core dumps

[Samuel Bronson]

At Sun, 19 Jul 2009 22:49:05 -0300,
Thiago Bauermann wrote:
> IIRC Ulrich Weigand considers that usage of the frame command to be 
> deprecated... I don't know the rationale though.

I believe the rationale is that it doesn't actually work very well :-).

Re: Backtracing broken core dumps

[Ulrich Weigand]

Samuel Bronson wrote:
> At Sun, 19 Jul 2009 22:49:05 -0300,
> Thiago Bauermann wrote:
> > IIRC Ulrich Weigand considers that usage of the frame command to be 
> > deprecated... I don't know the rationale though.
> 
> I believe the rationale is that it doesn't actually work very well :-).

Well yes, and more importantly that it cannot be made to work well,
because -as Paul Koning already pointed out- just specifying a stack
address simply does not reliably identify a stack frame.  On many
platforms, you *need* a PC in addition to the stack address in order
to be able to unwind further.  On some platforms (IA64) you may even
need yet more information (register stack address) ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com