# Handling crashes on Mac OS X: ordering of Mach exceptions versus POSIX signals

DevFeed: [Handling crashes on Mac OS X: ordering of Mach exceptions versus POSIX signals](<https://devfeed.tech/articles/handling-crashes-on-mac-os-x-ordering-of-mach-exceptions-versus-posix-signals-21565.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2013/08/handling-crashes-on-mac-os-x.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2013-08-07T20:25:00Z

Content type: tutorial

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [Operating system](<https://devfeed.tech/topics/operating-system.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [POSIX](<https://devfeed.tech/topics/posix.md>), [out-of-process](<https://devfeed.tech/topics/out-of-process.md>), [Remote Procedure Call (RPC)](<https://devfeed.tech/topics/rpc.md>)

Tags: [crash](<https://devfeed.tech/tags/crash.md>), [dialog](<https://devfeed.tech/tags/dialog.md>), [exception](<https://devfeed.tech/tags/exception.md>), [exception-handling](<https://devfeed.tech/tags/exception-handling.md>), [experimentation](<https://devfeed.tech/tags/experimentation.md>), [handler](<https://devfeed.tech/tags/handler.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [mac](<https://devfeed.tech/tags/mac.md>), [mac-os](<https://devfeed.tech/tags/mac-os.md>), [memory](<https://devfeed.tech/tags/memory.md>), [ordering](<https://devfeed.tech/tags/ordering.md>), [os](<https://devfeed.tech/tags/os.md>), [out-of-process](<https://devfeed.tech/tags/out-of-process.md>), [posix](<https://devfeed.tech/tags/posix.md>), [process](<https://devfeed.tech/tags/process.md>), [processes](<https://devfeed.tech/tags/processes.md>), [rpc](<https://devfeed.tech/tags/rpc.md>), [signal](<https://devfeed.tech/tags/signal.md>)

## AI overview

This article explains how Mac OS X handles hardware exceptions through POSIX signals and Mach exceptions. It reports that Mach exception handlers receive priority, while the kernel uses a first-chance Mach handler, a POSIX signal handler, and a second-chance Mach handler when handling faults and crashes.

## Source excerpt

Mac OS X is a curious operating system because its kernel is derived from two kernel codebases -- the Mach kernel and a BSD kernel -- that have been glued together. From these two ancestors, OS X inherits two different mechanisms for processes to handle hardware exceptions (a.k.a. faults): POSIX signals: In-process only. Registered per-process. The handler is always called on the thread that produced the fault. Mach exceptions: Allow both in-process and out-of-process handling. Can be registered per-thread and per-process. The handler is invoked via Mach RPC. On OS X, it's possible for a process to have both POSIX signal handlers and Mach exception handlers registered. It's not immediately obvious which of the two handlers will take priority and get invoked first, but experimentation shows that it's the Mach handler. If a process faults with a memory access error, the Mach exception handler for EXC_BAD_ACCESS gets invoked first, and if this handler returns KERN_FAILURE, the POSIX signal handler for SIGBUS will then be invoked. However, that's not the full story. OS X has a built-in Crash Reporter service which will create a crash dump if an application crashes and pop up a dialog box. Crash Reporter works via Mach exception handling and runs out-of-process. An application will normally have Crash Reporter's crash handler registered as one of its default Mach exception handlers. But what stops this handler from interfering with normal use of POSIX signals, if Mach exception handlers take priority over POSIX signals? The answer is that OS X's kernel has three steps for handling a hardware exception: First-chance Mach exception handler: The kernel tries to invoke the Mach exception handler registered for the type of fault that occurred, e.g. EXC_BAD_ACCESS. If there's no handler registered, it skips this step. If the handler returns KERN_SUCCESS, the kernel resumes the thread that faulted. POSIX signal handler: If the Mach exception handler was absent or returned KERN_