Bug 160555

Summary: gdb unable to decode call stack
Product: Red Hat Enterprise Linux 3 Reporter: Erik Kane <erikkane>
Component: gdbAssignee: Jeff Johnston <jjohnstn>
Status: CLOSED ERRATA QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: 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 Flags
sample file and steps to reproduce none

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