Bug 160555 - gdb unable to decode call stack
gdb unable to decode call stack
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gdb (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnston
Jay Turner
Depends On:
Blocks: 161600 168424 170275
  Show dependency treegraph
Reported: 2005-06-15 15:37 EDT by Erik Kane
Modified: 2015-01-07 19:10 EST (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2006-0141
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 12:02:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample file and steps to reproduce (6.33 KB, application/octet-stream)
2005-06-15 15:40 EDT, Erik Kane
no flags Details

  None (edit)
Description Erik Kane 2005-06-15 15:37:22 EDT
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):

How reproducible:

Steps to Reproduce:
1.see attached file sigaltstack.tar.bz2

Additional info:
Comment 1 Erik Kane 2005-06-15 15:40:20 EDT
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.
Comment 2 Andrew Cagney 2005-06-17 14:07:49 EDT
gdb for RHEL 3 U5; and gdb- addressed many backtrace
issues, can the problem be confirmed with that debugger?
Comment 4 Mike Simons 2005-06-22 19:09:54 EDT
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

Comment 5 Bert Barbe 2005-09-16 13:17:19 EDT
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 ?
Comment 6 Bert Barbe 2005-09-16 17:28:39 EDT
We narrowed down the proble to this patch:
# Stop a backtrace when a zero PC is encountered.
Patch106: gdb-6.3-framepczero-20040927.patch
Comment 11 Jeff Johnston 2005-12-02 12:12:29 EST
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-
Comment 16 Red Hat Bugzilla 2006-03-15 12:02:31 EST
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.


Note You need to log in before you can comment on or make changes to this bug.