<p>KSCrash ловит сбой, но стек сбоя пуст</p>

Созданный на 27 июл. 2017  ·  17Комментарии  ·  Источник: kstenerud/KSCrash

Я получаю отчет о сбоях от нашего пользователя, но обнаружил, что часть стека сбоев пуста.
2017-07-27 3 00 07

Это некоторые из необработанных отчетов о сбоях json.
1.txt
2.txt
3.txt

Самый полезный комментарий

Я посмотрю на эту проблему на следующей неделе

Все 17 Комментарий

Я получаю ту же проблему.

Я встречаю ту же проблему. Кто-нибудь починит?

Я встречаю ту же проблему, но почему?

Как воспроизвести проблему?

KSCrash установил для курсора imageAddress значение 0 в функции kssymbolicator_symbolicate() при анализе таблицы символов без символов отладки (Xcode -> настройки сборки -> Стиль полосы -> символы отладки)
Удачи ...

Я встречаю ту же проблему. Кто-нибудь починит?

Все три отчета, предоставленные автором, связаны с исключениями C++. Кто-нибудь получал не-C++-сбои без обратной трассировки?

@ bamx23 # 205 показывает, почему сбои C ++ не могут получить поврежденный стек. у меня вопрос, до сих пор проблема не решена? я все еще могу получить пустой стек, когда исключения C++ во встроенных фреймворках?

Я посмотрю на эту проблему на следующей неделе

@bamx23 bamx23 я получаю много пустого разбитого стека, «диагноз»: «Попытка разыменования нулевого указателя».
пустой.txt

Если встретите пустой стек для исключения C++, можете найти причину по этой проблеме. https://github.com/kstenerud/KSCrash/issues/205

Извините, лучше было сказать "в следующем месяце".
Я проверил KSCrash на сбой C++ из своего примера приложения, но потоки были в порядке. Может ли кто-нибудь предоставить пример кода, который воспроизводит проблему?

@chzhij5 брат, какую версию ks ты используешь? 1.15.8?

Привет! Мы исследовали проблему и возможные решения в нашей команде. Есть один:

В процессе установки KSCrashMonitor_CPPException мы можем использовать «хак», который описан и реализован на https://github.com/facebook/fishhook. Он позволяет перехватывать любой вызов функции динамически подключаемого бинарного файла. Итак, мы перехватываем __cxa_throw для всех загруженных двоичных файлов.

Если в какой-либо библиотеке есть слабый символ __cxa_throw (как в KSCrash в настоящее время), мы будем называть его так же, как и сейчас. Порядок будет таким: [fishhooked one] -> [weak one] -> [libc++abi one] .

Единственная проблема, которая не может быть решена, заключается в том, что если в каком-то двоичном файле есть сильный символ __cxa_throw , мы не можем его перехватить. Но я думаю, что в такой ситуации нет выхода.

@kstenerud , что ты думаешь? Мы прочитали ваш пост на stackoverflow , и кажется, что идея выше может решить эту проблему, по крайней мере, частично.

Мы можем пойти дальше и создать запрос на вытягивание, в котором fishhook будет зависеть от KSCrash (или подвида KSCrash, например, «KSCrash/Recording/ImprovedCPPExceptionsHandling»).

[fishhooked one] -> [weak one] -> [libc++abi one] .

На самом деле мы можем вызвать [libc++abi one] из [fishhooked one] в случае, если [weak one] не вызывает его, что удовлетворяет требованиям @kstenerud .

Звучит неплохо, мы попробуем на следующей неделе в нашем собственном приложении.

Вот PR: #375

Была ли эта страница полезной?
0 / 5 - 0 рейтинги