in man_ios_demo/dependence/CrashReporter.framework/Headers/PLCrashReporterConfig.h [36:98]
typedef NS_ENUM(NSUInteger, PLCrashReporterSignalHandlerType) {
/**
* Trap fatal signals via a sigaction(2)-registered BSD signal handler.
*
* PLCrashReporter's signal handler will supersede previously registered handlers; existing
* handlers will not be called. This behavior may be modified in a future release, and should
* not be relied upon as a mechanism to prevent existing signal handlers from being called.
*
* There are some limitations to signal-based crash handling on Mac OS X and iOS; specifically:
*
* - On Mac OS X, stack overflows will only be handled on the thread on which
* the crash reporter was initialized. This should generally be the main thread.
* - On iOS 6.0 and later, any stack overflows will not be handled due to sigaltstack() being
* non-functional on the device. (see rdar://13002712 - SA_ONSTACK/sigaltstack() ignored on iOS).
* - Some exit paths in Apple's Libc will deregister a signal handler before firing SIGABRT, resulting
* in the signal handler never being called (see rdar://14313497 - ___abort() disables SIGABRT signal
* handlers prior to raising SIGABRT). These __abort()-based checks are:
* - Implemented for unsafe memcpy/strcpy/snprintf C functions.
* - Only enabled when operating on a fixed-width target buffer (in which case the
* compiler rewrites the function calls to the built-in variants, and provides the fixed-width length as an argument).
* - Only trigger in the case that the source data exceeds the size of the fixed width target
* buffer, and the maximum length argument either isn't supplied by the caller (eg, when using strcpy),
* or a too-long argument is supplied (eg, strncpy with a length argument longer than the target buffer),
* AND that argument can't be checked at compile-time.
*/
PLCrashReporterSignalHandlerTypeBSD = 0,
#if PLCRASH_FEATURE_MACH_EXCEPTIONS
/**
* Trap fatal signals via a Mach exception server.
*
* If any existing Mach exception server has been registered for the task, exceptions will be forwarded to that
* exception handler. Should the exceptions be handled by an existing handler, no report will be generated
* by PLCrashReporter.
*
* @par Mac OS X
*
* On Mac OS X, the Mach exception implementation is fully supported, using publicly available API -- note,
* however, that some kernel-internal constants, as well as architecture-specific trap information,
* may be required to fully interpret a Mach exception's root cause.
*
* @par iOS
*
* On iOS, the APIs required for a complete implementation are not fully public.
*
* The exposed surface of undocumented API usage is relatively low, and there has been strong user demand to
* implement Mach exception handling regardless of concerns over API visiblity. Given this, we've included
* Mach exception handling as an optional feature, with both build-time and runtime configuration
* to disable its inclusion or use, respectively.
*
* @par Debugger Incompatibility
*
* The Mach exception handler executes in-process, and will interfere with debuggers when they attempt to
* suspend all active threads (which will include the Mach exception handler). Mach-based handling
* should not be used when a debugger is attached.
*
* @par More Details
*
* For more information, refer to @ref mach_exceptions.
*/
PLCrashReporterSignalHandlerTypeMach = 1
#endif /* PLCRASH_FEATURE_MACH_EXCEPTIONS */
};