https://sourceware.org/bugzilla/show_bug.cgi?id=20851
Bug ID: 20851
Summary: Mach-specific exceptions aren't caught correctly
Product: gdb
Version: 7.10
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: cosine at freesoft dot org
CC: bug-hurd at gnu dot org
Target Milestone: ---
gdb doesn't behave correctly when a Mach/Hurd application receives a memory
access exception. The memory faults get reported as unknown signals and the
program can't be restarted:
> Program received signal ?, Unknown signal.
> [Switching to Thread 812.8]
> 0x080eca46 in memcpy ()
> (gdb) cont
> Continuing.
> warning: Signal ? does not exist on this system.
> warning: Pid 812 died with unknown exit status, using SIGKILL.
>
> Program terminated with signal SIGKILL, Killed.
> The program no longer exists.
> (gdb)
Reproduce this bug by creating a ramdisk and mounting it with the /hurd/ext2fs
translator, then attach gdb to ext2fs and write data into the ramdisk until it
fills up. ext2fs will then receive a memory access fault.
I've tracked the problem down to the file gdb/common/signals.c in the gdb
source tree. This file includes a lot of statements like this:
> /* Mach exceptions. Assumes that the values for EXC_ are positive! */
> #if defined (EXC_BAD_ACCESS) && defined (_NSIG)
> if (hostsig == _NSIG + EXC_BAD_ACCESS)
> return GDB_EXC_BAD_ACCESS;
> #endif
The problem is that mach/exception.h isn't included at this point, so
EXC_BAD_ACCESS isn't defined and this code isn't included.
I've added #include <mach/exception.h> to signals.c, and produced a working
gdb:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> [Switching to Thread 769.8]
> 0x080eca46 in memcpy ()
> (gdb) cont
> Continuing.
Obviously, tacking a Mach-specific include into signals.c isn't the right
solution, so can somebody suggest a proper fix?
--
You are receiving this mail because:
You are on the CC list for the bug.
