Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160555 - gdb unable to decode call stack
Summary: gdb unable to decode call stack
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gdb
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnston
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks: 161600 168424 170275
TreeView+ depends on / blocked
 
Reported: 2005-06-15 19:37 UTC by Erik Kane
Modified: 2015-01-08 00:10 UTC (History)
6 users (show)

Fixed In Version: RHBA-2006-0141
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-15 17:02:30 UTC


Attachments (Terms of Use)
sample file and steps to reproduce (deleted)
2005-06-15 19:40 UTC, Erik Kane
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0141 qe-ready SHIPPED_LIVE gdb bug fix update 2006-03-14 05:00:00 UTC

Description Erik Kane 2005-06-15 19:37:22 UTC
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:
  - LD_ASSUME_KERNEL=2.4.1
  - 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):
gdb-6.1post-1.20040607.52

How reproducible:
Always

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

Additional info:

Comment 1 Erik Kane 2005-06-15 19:40:20 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.

Comment 2 Andrew Cagney 2005-06-17 18:07:49 UTC
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?


Comment 4 Mike Simons 2005-06-22 23:09:54 UTC
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



Comment 5 Bert Barbe 2005-09-16 17:17:19 UTC
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 21:28:39 UTC
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 17:12:29 UTC
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

Comment 16 Red Hat Bugzilla 2006-03-15 17:02:31 UTC
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



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