Re: EXC_BAD_ACCESS instead of SIGSEGV?
Re: EXC_BAD_ACCESS instead of SIGSEGV?
- Subject: Re: EXC_BAD_ACCESS instead of SIGSEGV?
- From: Jim Magee <email@hidden>
- Date: Thu, 6 Nov 2003 10:21:59 -0500
On Nov 6, 2003, at 7:59 AM, Simon Gray wrote:
I'm working with the GNU libsigsegv library
(http://sourceforge.net/projects/libsigsegv/) as I'm doing some
investigative work on page-mapping in Mac OSX 10.3 and I've run into a
problem:
The basic configure script tests signal handling via the code below
but no longer works in 10.3 as
a GDB trace shows that an EXC_BAD_ACCESS is generated instead of
SIGSEGV in the
function "crasher()", and it doesn't seem possible to install a signal
handler for
EXC_BAD_ACCESS (unsurprisingly, as its not a BSD signal).
Inexperienced as I am with Mach, I'm really not sure the best approach
to resolving this issue - any pointers?
All faults like these are delivered as Mach exceptions first. BSD has
installed a Mach exception handler that converts the Mach exception
into a signal. GDB installs its Mach exception handler BEFORE BSD's in
the chain of exception handlers to try for a watched task/process. So,
GDB sees and reports on Mach exceptions - not signals. That's why
EXC_BAD_ACCESS is confusing to you.
If you want to provide a signal handler for these, you need to install
handlers for SIGSEGV and SIGBUS. SIGSEGV applies when address is
completely invalid (nothing mapped there). SIGBUS applies for failures
when something is mapped there - but you can't access it (permissions,
force unmounts of a mapped file, etc...).
--Jim
PS: Because of where GDB sits in the exception path, you will still
see its handler kick in BEFORE the process' signal handler. You need
to continue past that spot in GDB to see if the process will handle it
itself. This also sometimes results in a "premature crashreport" as
the crash reporter mechanism also sits in front of the "last resort"
BSD signal delivery exception handler. We plan to address this in the
future by allowing exception handlers between BSD's signal delivery
handler and Mach's default (kill the task) behavior and moving
crashreporter's exception handler to sit there. We're still working
with the GDB folks to decide where they want their handler to sit (both
places have some value in a gdb environment).
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.