Bug 160555
Summary: | gdb unable to decode call stack | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Erik Kane <erikkane> | ||||
Component: | gdb | Assignee: | Jeff Johnston <jjohnstn> | ||||
Status: | CLOSED ERRATA | QA Contact: | Jay Turner <jturner> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | aoliva, bert.barbe, cagney, jjohnstn, msimons, srevivo | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | RHBA-2006-0141 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-03-15 17:02:30 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 161600, 168424, 170275 | ||||||
Attachments: |
|
Description
Erik Kane
2005-06-15 19:37:22 UTC
Created attachment 115500 [details]
sample file and steps to reproduce
Environment:
kernel-smp-2.4.21-15.0.3.EL.i686
glibc-2.3.2-95.30.i686
gcc-3.2.3-34.i386
gdb-6.1post-1.20040607.52
thread.c
- 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
function.
trace.c
- contains a function which will setup and invoke psprocinfo on
the process that calls the function.
psprocinfo
- is a shell script which will attach gdb to a given process id
get useful information like a call stack.
iterate
- is a perl script to run a test program with a selection of
command line arguments.
gdb 6.3.0.0-0.30.1 for RHEL 3 U5; and gdb-6.3.0.0-0.31 addressed many backtrace issues, can the problem be confirmed with that debugger? This bug replicates exactly as described, using the newest RHEL3 gdb-6.3.0.0-0.30.1.i386 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. Patch106: gdb-6.3-framepczero-20040927.patch 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-6.3.0.0-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. http://rhn.redhat.com/errata/RHBA-2006-0141.html |