Kscrash: Неправильные трассировки стека для исключений C++ во встроенных платформах

Удачи с этим? Я пытаюсь интегрировать KSCrash в свое приложение, но застрял из-за встроенной среды.
Пожалуйста, дайте мне знать, если у вас есть работа для этого.

Не повезло, и я не верю, что это возможно, по крайней мере, не в нашем случае использования. Это мое понимание ситуации:

KSCrash записывает трассировку стека путем создания собственной реализации __cxa_throw, которая разрешает доступ к стеку до того, как он будет раскручен libc++. Это работает до тех пор, пока KSCrash статически связан с кодом C++, поскольку компоновщик найдет и использует __cxa_throw из формы KSCrash вместо реализации в libc++. Но в случае встраиваемого фреймворка, ссылающегося на libc++, будет использоваться реализация __cxa_throw из libc++, так как фреймворк не знает о коде в KSCrash. Возможно, есть обходной путь, если у вас есть контроль над встроенной структурой, но в нашем случае это не сработает.

Пожалуйста, дайте мне знать, если вы найдете решение.

У меня есть контроль над встроенной структурой. Но не уверен, как это исправить.
Я также пробовал PLCrashReporter, с ним такая же проблема.

Означает ли это, что KSCrash в идеале должен быть построен как статическая библиотека и связан с приложением, чтобы, по крайней мере, перехватывать исключения C++, возникающие в коде приложения?

Но это все равно оставит любые исключения, созданные в любой динамической библиотеке, не перехваченными KSCrash, если я правильно понимаю ваш отчет об ошибке @pdrtrifork ? Если мы контролируем встроенные динамические библиотеки, можем ли мы связать статическую библиотеку с каждой из них только с помощью этой заглушки __cxa_throw, которая просто отложится на общий обработчик KSCrash?

Ха, так что, расследуя это, я оказался здесь http://stackoverflow.com/questions/36846628/conditionally-overriding-cxa-throw , который был открыт нашим собственным @kstenerud 😄

В любом случае, PR #219 должен, по крайней мере, предотвращать сбои во время отчетов о сбоях.

@kstenerud Я думаю, что эту проблему следует переименовать во что-то вроде _ «Отсутствующие трассировки стека для исключений C ++, созданных из изображений, не связанных статически с KSCrash» _. Насколько я могу судить, переопределение __cxa_throw работает только в том же образе, что и KSCrash, поэтому:

• если KSCrash построен как статическая библиотека и связан с основным приложением, вы получите обратные трассировки исключений C++, если исключение выдается в основном приложении, но не когда возникает из динамически загружаемых библиотек.
• если KSCrash построен как статическая библиотека и связан с динамической библиотекой (оболочкой), вы получите обратные трассировки исключений C++, если исключение выдается из этой динамической библиотеки, но не из основного приложения или других динамически загружаемых библиотек.
• если KSCrash построен как разделяемая библиотека (фреймворк), вы получаете обратные трассировки исключений C++, если исключение выдается из KSCrash, но не из основного приложения или других динамически загружаемых библиотек.

Последнее повлияет на таких клиентов, как sentry-swift , https://docs.sentry.io/clients/cocoa/ , которые используют KSCrash в качестве фреймворка.

После дальнейшего расследования кажется, что мой предыдущий комментарий был неверным:

Я думаю, что эту проблему следует переименовать во что-то вроде _"Отсутствующие трассировки стека для исключений C++, созданных из изображений, не связанных статически с KSCrash"_.

В случае, если KSCrash подключается к основному приложению как статическая библиотека:

• MyApplication ( main.o , libKSCrash.a )
  
  
  
  • libDynamicLibrary.dylib ( lib.o )
  
  
  • /usr/lib/libc++abi.dylib
  
  

Любые исключения, созданные из MyApplication , попадут в libKSCrash.a::__cxa_throw . Кроме того, поскольку libKSCrash.a объявляет __cxa_throw как weak , привязка MyApplication не завершается ошибкой, если main.o имеет собственный __cxa_throw переопределить. Все идет нормально. Однако, как замечено в этом отчете об ошибке, любые исключения, созданные из libDynamicLibrary.dylib , не вызовут libKSCrash.a::__cxa_throw и закончатся в /usr/lib/libc++abi.dylib::__cxa_throw .

В случае, если KSCrash подключается к основному приложению как динамическая библиотека:

• MyApplication ( main.o )
  
  
  
  • libKSCrash.dylib
  
  
  • /usr/lib/libc++abi.dylib
  
  
  • libDynamicLibrary.dylib ( lib.o )
  
  
  • /usr/lib/libc++abi.dylib
  
  

Любые исключения, созданные из MyApplication , попадут в libKSCrash.dylib::__cxa_throw , но только если:

1. __cxa_throw экспортируется из libKSCrash.dylib
2. __cxa_throw не помечен как weak

Если __cxa_throw помечен как weak ( 0000000000002e90 (__TEXT,__text) weak external ___cxa_throw ), то при связывании libKSCrash.dylib компоновщик, кажется, смотрит на /usr/lib/libc++abi.dylib , находит не -weak __cxa_throw и сделать вывод, что libKSCrash.dylib::__cxa_throw следует игнорировать. Во время поиска символа во время выполнения во время броска из MyApplication libKSCrash.dylib::__cxa_throw затем игнорируется.

Это наводит меня на мысль, что атрибут weak следует условно добавлять только при сборке KSCrash как статической библиотеки.

Как и в первом варианте использования, любые исключения, созданные из libDynamicLibrary.dylib , не вызовут libKSCrash.dylib::__cxa_throw и закончатся в /usr/lib/libc++abi.dylib::__cxa_throw .

Эта проблема потенциально может быть устранена с помощью некоторых низкоуровневых исправлений во время выполнения загруженных изображений с неопределенными ссылками на __cxa_throw . С помощью тестового приложения, упомянутого в статье, я убедился, что этот метод действительно работает и для __cxa_throw .

Я пытаюсь проверить сбой в фреймворке в своем приложении. Когда я пытаюсь получить журнал сбоев, я вижу, что трассировка стека не показывает фактический сбой, вместо этого происходит сбой KSCrash.

Это та же проблема?

Сбой потока 0:
0 libsystem_kernel.dylib 0x0000000181cc5348 0x181ca4000 + 136008 (__pthread_kill + 8)
1 libsystem_pthread.dylib 0x0000000181ddd7a4 0x181dd6000 + 30628 ( + 360)
2 libsystem_c.dylib 0x0000000181c34fd8 0x181bd2000 + 405464 (отмена + 140)
3 libc++abi.dylib 0x0000000181698068 0x181696000 + 8296 ( + 132)
4 libc++abi.dylib 0x0000000181698210 0x181696000 + 8720 ( + 304)
5 libobjc.A.dylib 0x00000001816c0810 0x1816b8000 + 34832 ( + 124)
6 KSCrash 0x00000001054a0590 0x10549c000 + 17808 (kscm_cppexception_getAPI + 280)
7 libc++abi.dylib 0x00000001816b054c 0x181696000 + 107852 ( + 16)
8 libc++abi.dylib 0x00000001816b0158 0x181696000 + 106840 (__cxa_rethrow + 144)
9 libobjc.A.dylib 0x00000001816c06e8 0x1816b8000 + 34536 (objc_exception_rethrow + 44)
10 CoreFoundation 0x0000000182072344 0x18206a000 + 33604 (CFRunLoopRunSpecific + 544)
11 GraphicsServices 0x0000000183f03f84 0x183ef9000 + 44932 (GSEventRunModal + 100)
12 UIKit 0x000000018b61e880 0x18b5ab000 + 473216 (UIApplicationMain + 208)

@torarnv Привет, не могли бы вы поделиться с нами своей успешной демонстрацией mach-o-hook? Я столкнулся с EXC_BAD_ACCESS при попытке mach_hook __cxa_throw.

void ter_handler(){
    printf("custom handler\n");
}

void test(){
    throw std::runtime_error("test function");
}

static void (*orig_throw)(void * thrown_exception, std::type_info *tinfo, void (*dest)(void *));

void hooked_throw(void * thrown_exception, std::type_info *tinfo, void (*dest)(void *)){
    printf("hooked_throw...\n");
    return orig_throw(thrown_exception, tinfo, dest);
}

int main(int argc, char * argv[])
{
    <strong i="5">@autoreleasepool</strong> {

        struct rebinding binds[1];
        struct rebinding bind1 = {"__cxa_throw", (void *)hooked_throw, (void **)&orig_throw};
        binds[0] = bind1;
        rebind_symbols(binds, 1);

        std::set_terminate(ter_handler);
        try {
            throw std::runtime_error("test error");
        }
        catch (...){
            printf  ("catch exception\n");
        }

        test();
    }
}

попробуй это... удачи

Я встречаю один краш с KSCrash,

как это решить?

Мы создали PR, реализующий динамический хук, упомянутый выше @huakucha : #375