Bug 385941 - gdb incorrectly evaluates stdout/stderr
gdb incorrectly evaluates stdout/stderr
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
8
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-15 17:57 EST by bwelling
Modified: 2009-01-09 02:25 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:25:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bwelling 2007-11-15 17:57:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.9) Gecko/20071105 Fedora/2.0.0.9-1.fc8 Firefox/2.0.0.9

Description of problem:
In some cases, gdb appears to be evaluating the stderr and stdout variables as 32-bit integers, instead of as pointer values.  attempting to use them as parameters to functions called from within gdb (which expect FILE * parameters) causes a SIGSEGV.

Version-Release number of selected component (if applicable):
gdb-6.6-35.fc8

How reproducible:
Always


Steps to Reproduce:
1.Compile the following program with -g -O0

#include <unistd.h>
#include <stdio.h>

int main()
{
        printf("stdout = %p\n", stdout);
        printf("stderr = %p\n", stderr);
        sleep(1000);
}

2. Run the program from within gdb
3. The program will print something like:

stdout = 0x3c88151760
stderr = 0x3c88151840

4. Hit ^C to interrupt execution (while the sleep is executing)
5. From within gdb, execute 'p stdout' and 'p stderr'

(gdb) p stdout
$1 = -2011883680
(gdb) p stderr
$2 = -2011883456

These are obviously wrong, because neither stdout nor stderr should be interepreted as integers.

6. Execute 'p/x stdout' and 'p/x stderr'

$3 = 0x88151760
(gdb) p/x stderr
$4 = 0x88151840

These are the same variables as above, but truncated to 32 bits.  This is bad.

7. Print the values explicity cast to (struct _IO_FILE *)

(gdb) p/x (struct _IO_FILE *)stdout
$5 = 0xffffffff88151760
(gdb) p/x (struct _IO_FILE *)stderr
$6 = 0xffffffff88151840

The pointers are being sign extended, which explains the segfault.  For some other reason that I can't explain, the sign extension doesn't always happen; this sometimes prints the correct result.

Actual Results:
The program crashed dereferencing the invalid pointer.

Expected Results:
The program should not have crashed.

Additional info:
Comment 1 Jan Kratochvil 2007-11-16 15:40:33 EST
The primary problem is that glibc-debuginfo rpm is not installed there.

There should be even a warnings for that while running GDB:
(gdb) r
Starting program: /tmp/bz385941 

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/ea/5b2fb654311e2dc8beacf2f19c1c6d172ba93d.debug
stdout = 0x3166b51760
stderr = 0x3166b51840

If you do
yum install \
 /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug \
 /usr/lib/debug/.build-id/ea/5b2fb654311e2dc8beacf2f19c1c6d172ba93d.debug
everything should be fine as glibc-debuginfo gets installed.

That it sometimes happens and sometimes not depends on the fact if you first
  (gdb) p stdout
from the main() function or if you first reference `stdout' from the context of
glibc by breaking it by CTRL-C during __nanosleep_nocancel().  In that moment
GDB finds yout that glibc really defined `stdout' (so it stops searching for the
definition from main()) but as you do not have glibc-debuginfo installed it
cannot find out the type of `stdout' and defaults it to `int'.

Possible improvements:

(1) If the global symbol is defined for a compilation unit but it has no
    associated debug info, still try to find that debug info in the other
    compilation units.

(2) Symbols of size 8 (or more general rules for types) could default to `long'
    (not `int').

Thanks for the feedback.

P.S.: Please check http://www.jankratochvil.net/project/xbill/ . :-)
Comment 2 Bug Zapper 2008-11-26 03:28:34 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Bug Zapper 2009-01-09 02:25:54 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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