Чтобы расширить ответ Андреаса -
Я реализовал поддержку разработки в транке для - [PLCrashReporter setCrashCallbacks:], который разрешает выполнение функции после сбоя до выхода из программы.
Первоначально это не было включено из-за сложности реализации асинхронно-безопасного кода, который может быть выполнен в контексте аварийного процесса - это достаточно сложно сделать, и я не думал, что кто-то захочетсделайте это.
Чтобы процитировать документацию, которую я написал для функции в стволе PLCrashReporter (у меня нет опубликованной копии, поскольку функция еще не была выпущена):
Async-Безопасное руководство по программированию
Plausible CrashReporter обеспечивает поддержку выполнения функции, указанной приложением, в контексте обработчика сигналов репортера аварий, после того, как отчет о сбое был записан на диск.Это регулярно запрашиваемая функция, позволяющая реализовать финализацию приложения в случае сбоя.Однако написание кода, предназначенного для выполнения внутри обработчика сигналов, исключительно сложно и не рекомендуется.
Обработчики программ и сигналов
Когда обработчик сигналов называется нормальным потоком программыпрервана, и ваша программа находится в неизвестном состоянии.Блокировки могут удерживаться, куча может быть повреждена (или находится в процессе обновления), и ваш обработчик сигнала может вызвать функцию, которая выполнялась во время сигнала.Это может привести к взаимоблокировкам, повреждению данных и завершению программы.
Асинхронные функции
Подмножество функций определено ОС как асинхронно-безопасное и безопасно вызывается изнутри.обработчик сигнала.Если вы реализуете собственный обработчик после аварии, он должен быть асинхронным.Таблица асинхронно-безопасных функций, определенных POSIX, и дополнительная информация доступны в руководстве по программированию CERT - SIG30-C .
В частности, сама среда выполнения Objective C не является асинхронной.безопасный, и Objective-C не может использоваться в обработчике сигнала.