Вы указали, что разыменовываете неинициализированный указатель.Но у меня недостаточно информации из отчета, который вы опубликовали, чтобы узнать, был ли это (возможно, по счастливой случайности) ноль, или просто мусорная память.Я предполагаю, что в какой-то момент вы потерпели крах с EXC_BAD_ACCESS (эквивалент сигнала SIGBUS или SIGSEGV, в зависимости).
критический бит информации здесь былу вас установлен обработчик сигнала.
Обработчики сигналов обычно (но не всегда) работают в аварийном потоке, используя тот же стек.Ядро внедряет обработчик, используя эту функцию _sigtramp.После доставки сигнала текущее состояние стека содержало информацию, необходимую для отслеживания плохого доступа к памяти.Но вместо этого был вызван ваш обработчик сигнала.Таким образом, он работал, изменяя стек, как это было.
Затем ваш обработчик сигналов завершился каким-то образом.Можно настроить обработчик сигнала, используя sigaction так, чтобы состояние процесса восстанавливалось до момента, предшествующего событию сбоя.Я не уверен, как был настроен ваш обработчик сигналов.Но, в конечном счете, я собираюсь предположить, что процессу было разрешено завершиться.
В этот момент Apple ReportCrash был бы запущен и собирал бы следы для всех потоков в любом состоянии вашего сигналаОбработчик оставил их .Это очень важно, потому что это не обязательно состояние сбоя.
Если сложить сложнее, backtrace_symbols_fd - это вовсе не безопасно для использования из обработчика сигнала.Асинхронная безопасность является сложной задачей, и запуск кода из обработчика сигналов очень труден для понимания .Есть очень мало вещей, которые вы можете сделать безопасно.Кроме того, я почти уверен, что backtrace_symbols_fd выделяет память.Итак, если ваш сбой был где-то в распределителе памяти, и это звучит так, как будто вы были, вы определенно рискуете зайти в тупик.Судя по обратному следу, похоже, что именно это и могло произойти.За подробностями обращайтесь к man sigaction.
Хуже того, раскрутка стека над фреймом обработчика сигнала особенно сложна из-за волшебства, которое ядро выполняет для запуска вашего обработчика.Вот почему там находится кадр ???.
Резюме:
Без установленного обработчика сигналов ReportCrash от Apple мог бы создать правильную (и, вероятно, полезную) обратную трассировку для потока, вызывающего сбой.
Трассировка стека, которую вы включили, невелика, но трудно точно понять, почему.Похоже, что backtrace_symbols_fd не справился с работой по раскрутке, возможно, из-за того, что он не подходит для использования из обработчика сигнала, возможно, потому что он не поддерживается достаточно хорошим механизмом раскрутки стека для этой ситуации.Но без дополнительной информации мне трудно это знать.Я удивлен тем, что верхняя рамка была _sigtramp.Это не имеет большого смысла.Это заставляет меня думать, что, возможно, что-то пошло не так в самом обработчике сигнала. возможно аварийно завершить во второй раз в вашем обработчике.
Обратные следы Apple (генерируемые, например, ReportCrash, backtrace_symbols_fd или NSThread * callStackReturnAddresses), безусловно, можно доверять при условиивы осторожно используете их в безопасных условиях.