backtrace issues

backtrace issues

[David Carlton]

Does GDB have known issues with backtraces on programs compiled with a
recent GCC but with a C library compiled with an old GCC?  It happens
not infrequently around here that we get backtraces that GDB 5.3 can
read but where mainline GDB can't get past the first few frames.  I
know I've seen this in the following situation (user code is compiled
with GCC 3.2, system libraries are from Red Hat 7.3):

* We have user code, which seg faults.

* Our signal handler gets called.  This signal handler then prints out
  a (useful) backtrace, using the functions provided by the C
  library.  It then calls abort().

* A core file is generated.

Then, when we try to read the core file, mainline GDB gets confused a
few frames down (right around the signal handler), while GDB 5.3 has
no problem with the core file.

Is this a known issue?  Is there anything useful I can do to help
diagnose the issue?  Obviously I'll try to produce a stripped-down
example where this happens, but if I'm not able to do so, I can
certainly run GDB on itself to see what's going on, if anybody can
point me to useful places to look at.

David Carlton
carlton@kealia.com

Re: backtrace issues

[David Carlton]

On Fri, 06 Feb 2004 10:32:07 -0800, David Carlton <carlton@kealia.com> said:

> Does GDB have known issues with backtraces on programs compiled with a
> recent GCC but with a C library compiled with an old GCC?

Actually, the fact that the program was compiled with a recent GCC
seems to be irrelevant.

I did come up with a stripped-down test case; I've filed PR gdb/1545
about it.

David Carlton
carlton@kealia.com

Re: backtrace issues

[Joel Brobecker]

> Actually, the fact that the program was compiled with a recent GCC
> seems to be irrelevant.
> 
> I did come up with a stripped-down test case; I've filed PR gdb/1545
> about it.

Note that I have also reported a similar problem with the
pthread_library. With 5.3, GDB was doing an approximate job, and
lost a few frames in the way, but we still had the useful part of
the backtrace more or less intact. With the new frame code, however,
the unwinder just stops :-( and leaves the user with a bactracke which
he can't use.

Given the level of optimization involved in the code from which we
wanted to backtrace from, it was determined that there was very little
that we could do, which is unfortunate because it used to be able
to get out of this quagmire before...

At the time when we discussed this, we argued that the only hope was
with dwarf2 CFI, but it just so happens that I noticed the exact same
sort of problem on Windows XP (where we don't have dwarf-2 :-/).

I have been brooding for a while over this, and really don't see any
solution to this, right now. Maybe it's unfair to say this: I find
the new frame code well structured and blissfully free of all the hacks
we used to have. However, it seems less tolerant to difficult cases,
where we just stop unwinding while we used to be able to have a useful
backtrace with 5.3.

(please don't see this as a complaint or don't think I am pointing
finger at anybody - if I had found a better solution, believe me, 
I would have sent a suggestion).

-- 
Joel

Re: backtrace issues

[Andrew Cagney]

> At the time when we discussed this, we argued that the only hope was
> with dwarf2 CFI, but it just so happens that I noticed the exact same
> sort of problem on Windows XP (where we don't have dwarf-2 :-/).
> 
> I have been brooding for a while over this, and really don't see any
> solution to this, right now. Maybe it's unfair to say this: I find
> the new frame code well structured and blissfully free of all the hacks
> we used to have. However, it seems less tolerant to difficult cases,
> where we just stop unwinding while we used to be able to have a useful
> backtrace with 5.3.
> 
> (please don't see this as a complaint or don't think I am pointing
> finger at anybody - if I had found a better solution, believe me, 
> I would have sent a suggestion).

Have a look at the output from "set debug frame 1" (yes it is extreemly 
verbose but all the info is in there).  Two things could be going wrong 
(only two?):

- the debug info for the frame is wrong (gdb looses)
If you comment out the code adding the dwarf2 sniffer does it work 
better?  Things to do one day include "set backtrace unwind dwarf2 
{on,off}".  That it happens with XP indicates it is actually ...

- we lost something in translation
It's already using the traditional unwinder but the conversion frayed an 
edge case - straight debugging.

Andrew