[gst-devel] Question: How do I obtain a better gdb back trace of segmentation faults?
ds at schleef.org
Fri Jan 7 12:56:05 CET 2005
On Fri, Jan 07, 2005 at 01:49:21AM +0100, Ronald S. Bultje wrote:
> > (gdb) bt
> > #0 0x4063ade5 in ?? ()
> It might be that the binaries have been stripped at some point.
Permit me to be pedantic for a minute...
> #24 0x00000294 in ?? ()
> #25 0x00000004 in ?? ()
These return addresses are not in a code region.
> #28 0xbfffe4f8 in ?? ()
> #30 0xbfffe4fc in ?? ()
These return addresses are on the stack. Valid return addresses
are typically 0x01nnnnnn (for addresses in the main program) or
0x40nnnnnn (for addresses in shared libraries). These areas are
somewhat configurable, though, so certain "enhanced" distros might
use different areas.
This kind of stack happens if frames aren't properly linked on the
stack. This is caused either by inline assembly screwing with the
%ebp register (heh, liboil does this in a few places), or some code
being compiled without -fomit-frame-pointer (a certain source-based
distro often does this), or plain ol' stack smashing. Probably
other reasons, too.
It would be _really_ nice if gdb could detect such mismatched
linking, and reconstruct stack frames as best as possible. Messed
up stacks seem to be the rule rather than the exception for me these
days. Fortunately, I have a powerpc machine on which I can reproduce
the hariest stack confusion, since powerpc stack frames are much
more robust, and it's not possible to use -fomit-frame-pointer.
More information about the gstreamer-devel