Bug 385941
| Summary: | gdb incorrectly evaluates stdout/stderr | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | bwelling |
| Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-01-09 07:25:54 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: | |||
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/ . :-) 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 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. |
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: