This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/15573] New: Decode fatal signals to show faulting address, access type, etc.
- From: "luto at mit dot edu" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 04 Jun 2013 18:37:33 +0000
- Subject: [Bug gdb/15573] New: Decode fatal signals to show faulting address, access type, etc.
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15573
Bug ID: 15573
Summary: Decode fatal signals to show faulting address, access
type, etc.
Product: gdb
Version: 7.5
Status: NEW
Severity: enhancement
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: luto at mit dot edu
I have a (buggy) program that segfaulted while running in gdb. gdb said:
Program received signal SIGSEGV, Segmentation fault.
followed by a stacktrace. If I weren't using gdb, my program's signal handler
would have run and displayed a far more useful error message:
Caught fatal signal: Segmentation fault (Address not mapped to object [0x28])
Dying due to fatal signal Segmentation fault in pid 14030 / tid 14030
The error was "not mapped" at address 28. The CPU reported page not present
reading from 28.
This is on x86_64. That information comes from psiginfo (the first line) and a
custom decoder that reads SEGV_MAPERR as "not mapped" and pulls the number 28
from siginfo (the first time) and cr2 (the second time). The "page not
present" part is the low bit of the error code (from ucontext); the alternative
is "protection violation", which is a different error. The "reading from" part
is really quite handy when debugging; it distinguishes read faults from write
faults. The alternatives are "executing from" and "writing to".
Having gdb decode this information would save a lot of time tracking down bugs.
--
You are receiving this mail because:
You are on the CC list for the bug.