Red Hat Bugzilla – Bug 160555
gdb unable to decode call stack
Last modified: 2015-01-07 19:10:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Description of problem:
On RHEL3 in gdb is unable to decode the call stack from the main
thread of when _all_ of the following are true:
- the process creates at least one thread
- the _main_ process SEGVs
This problem does not exist when LD_ASSUME_KERNEL is not set
and this problem did not occur on RHEL2.1.
This is a relatively complicated situation to recreate, so
unfortunately the test program is rather complicated...
Please review the Sample_Run run, for information about how to run.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.see attached file sigaltstack.tar.bz2
Created attachment 115500 [details]
sample file and steps to reproduce
- contains the main function driver for this test, which will
based on command line flags create threads (or not), then
core dump itself where the signal handler will invoke the trace
- contains a function which will setup and invoke psprocinfo on
the process that calls the function.
- is a shell script which will attach gdb to a given process id
get useful information like a call stack.
- is a perl script to run a test program with a selection of
command line arguments.
gdb 188.8.131.52-0.30.1 for RHEL 3 U5; and gdb-184.108.40.206-0.31 addressed many backtrace
issues, can the problem be confirmed with that debugger?
This bug replicates exactly as described, using the newest RHEL3
Please try it yourself...
LD_ASSUME_KERNEL=2.4.9 ./thread T
==== Local Backtrace
#0 0xb75a31bb in waitpid () from /lib/i686/libpthread.so.0
#1 0xb75a6398 in __JCR_LIST__ () from /lib/i686/libpthread.so.0
#2 0x00000000 in ?? ()
---- Local Backtrace
I tested with gdb 6.3 from gnu.org and there the backtrace works ok.
Seems the problem must be in one of the patches redhat applied to gdb 6.3 ?
We narrowed down the proble to this patch:
# Stop a backtrace when a zero PC is encountered.
The patch referred to in comment #6 should not be removed from gdb. When the pc
is zero, gdb is in essence missing debug information and may be lost. In most
instances, attempting to backtrace past such a point results in garbage traces
that may not have an end condition (i.e. infinite backtraces).
To alleviate the problem specified here, a new set backtrace sub-command has
been added which gives the user the option of forcing a trace past a zero pc
value. To use it:
set backtrace past-zero-pc on
By default, the option will be off. The option can be later set off via:
set backtrace past-zero-pc off
The sub-command has been added as of gdb-220.127.116.11-1.90
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.