Bug 104763
Summary: | gdb can't get a stack | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Andrew Schultz <ajschult784> |
Component: | gdb | Assignee: | Elena Zannoni <ezannoni> |
Status: | CLOSED ERRATA | QA Contact: | Jay Turner <jturner> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | brobecker, cagney, jjohnstn, srevivo |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
URL: | http://bugzilla.mozilla.org/show_bug.cgi?id=208184 | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-12-21 19:36:55 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: | 104781, 108892 | ||
Bug Blocks: |
Description
Andrew Schultz
2003-09-20 17:54:08 UTC
What happens if you try: (gdb) x/i 0xffffe002 both gdb (RH9 and rawhide) say: (gdb) x/i 0xffffe002 0xffffe002: Cannot access memory at address 0xffffe002 (gdb) x/i 0x400c7a30 0x400c7a30 <PR_Wait+160>: mov 0x8(%ebp),%edx oops > both gdb (RH9 and rawhide) say:
> (gdb) x/i 0xffffe002
> 0xffffe002: Cannot access memory at address 0xffffe002
GDB isn't able to read the "vsyscall" page at/around 0xffffe002, isn't able to
figure out how to backtrace out of that code :-( There isn't much GDB can do
here - think of trying to fly blind
Recommend down gradeing to a kernel that doesn't include the "vsyscall" page, or
disabling the vsyscall page (not sure how this is done).
Actually, I think that 0xffffe002 was a red-herring. See: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00440.html (note that the message above also provides a simpler reproducer) While it is true that the debugger can not yet read the memory at that address, and therefore can only guess as to how to unwind from it, it seems to me that it is doing a better job now (6.0 and head) compared to 5.3. The real problem, I think, is that GDB is unable to unwind correctly past the pthread_cond_wait() function: The function is frameless, and to make things more difficult, the stack space allocated during the lifetime of that function is adjusted twice. The unwinder only sees the first allocation, and therefore miscalculates the "virtual frame" size, and hence fetches the value of the saved registers from the wrong location. The only hope that was expressed during the discussion mentioned by the URL above is by adding DWARF2 CFI info to the NPTL. I think this is now fixed. I'll put in modified state. I'll close this in a week if I don't hear back. 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-2004-561.html |