Kscrash: 임베디드 프레임워크의 C++ 예외에 대한 잘못된 스택 추적

이것에 행운이 있습니까? 내 앱에 KSCrash를 통합하려고 하는데 임베디드 프레임워크 때문에 멈췄습니다.
이 문제를 해결할 수 있는 방법이 있으면 알려주세요.

운이 없습니다. 그리고 저는 그것이 가능하다고 믿지 않습니다. 적어도 우리의 사용 사례에서는 그렇지 않습니다. 이것은 상황에 대한 나의 이해입니다.

KSCrash가 스택 추적을 기록하는 방법은 libc++에 의해 해제되기 전에 스택에 대한 액세스를 허용하는 __cxa_throw의 자체 구현을 만드는 것입니다. 이것은 링커가 libc++에서 구현하는 대신 KSCrash에서 __cxa_throw를 찾아 사용하기 때문에 KSCrash가 C++ 코드와 정적으로 연결되어 있는 한 작동합니다. 그러나 libc++에 링크되는 임베디드 프레임워크의 경우 프레임워크가 KSCrash의 코드에 대해 알지 못하기 때문에 libc++의 __cxa_throw 구현이 사용됩니다. 임베디드 프레임워크를 제어할 수 있는 경우 해결 방법이 있을 수 있지만 이 사용 사례에서는 작동하지 않습니다.

해결책을 찾으면 알려주십시오.

임베디드 프레임워크를 제어할 수 있습니다. 그러나 그것을 고칠 방법이 확실하지 않습니다.
나는 또한 PLCrashReporter와 같은 문제를 시도했습니다.

이것은 KSCrash가 최소한 애플리케이션 코드에서 throw된 C++ 예외를 포착하기 위해 이상적으로 정적 라이브러리로 빌드되고 애플리케이션에 연결되어야 함을 의미합니까?

그러나 버그 보고서 @pdrtrifork 를 올바르게 이해하면 KSCrash가 포착하지 못한 동적 라이브러리에서 예외가 발생하게 됩니다. 내장된 동적 라이브러리를 제어하는 ​​경우 공유 KSCrash 처리기를 참조하는 __cxa_throw 스텁을 사용하여 정적 라이브러리에서 각 라이브러리에 연결할 수 있습니까?

하, 그래서 이것을 조사하면서 나는 http://stackoverflow.com/questions/36846628/conditionally-overriding-cxa-throw 에 이르렀습니다. 이것은 우리 자신의 @kstenerud 에 의해 열렸습니다 😄

어쨌든 PR #219는 최소한 충돌 보고 중에 충돌을 방지해야 합니다.

@kstenerud 제 생각에는 이 문제의 이름을 _"KSCrash와 정적으로 연결되지 않은 이미지에서 발생한 C++ 예외에 대한 스택 추적 누락"_과 같은 것으로 이름을 바꿔야 한다고 생각합니다. 내가 말할 수 있는 한 __cxa_throw 재정의는 KSCrash와 동일한 이미지에서만 작동하므로 다음과 같습니다.

• KSCrash가 정적 라이브러리로 빌드되고 기본 앱에 링크된 경우 기본 앱에서 예외가 throw되면 C++ 예외 역추적이 발생하지만 동적으로 로드된 라이브러리에서 throw될 때는 그렇지 않습니다.
• KSCrash가 정적 라이브러리로 빌드되고 동적(래퍼) 라이브러리에 링크된 경우 해당 동적 라이브러리에서 예외가 throw되면 C++ 예외 역추적이 발생하지만 기본 앱이나 동적으로 로드된 다른 라이브러리에서 throw될 때는 그렇지 않습니다.
• KSCrash가 공유 라이브러리(프레임워크)로 빌드된 경우 KSCrash에서 예외가 throw되면 C++ 예외 역추적이 발생하지만 기본 앱 또는 기타 동적으로 로드된 라이브러리에서 throw될 때는 그렇지 않습니다.

후자는 sentry-swift , https://docs.sentry.io/clients/cocoa/ 와 같은 클라이언트에 영향을 미치며, 이는 KSCrash를 프레임워크로 포함합니다.

추가 조사 후 내 이전 의견이 잘못된 것 같습니다.

이 문제는 _"KSCrash와 정적으로 링크되지 않은 이미지에서 발생한 C++ 예외에 대한 스택 추적 누락"_과 같은 이름으로 변경되어야 한다고 생각합니다.

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 $로 선언하므로 $ main.o 에 자체 __cxa_throw 가 있으면 $ MyApplication 연결이 실패하지 않습니다. __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 그래픽 서비스 0x0000000183f03f84 0x183ef9000 + 44932(GSEventRunModal + 100)
12 UIKit 0x000000018b61e880 0x18b5ab000 + 473216 (UIApplicationMain + 208)

@torarnv 안녕하세요, 성공적인 mach-o-hook 데모를 공유해 주시겠습니까? mach_hook __cxa_throw를 시도할 때 EXC_BAD_ACCESS가 발생했습니다.

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와 하나의 충돌을 만납니다.

그것을 해결하는 방법?

위에서 언급한 @huakucha : #375 동적 후크를 구현하는 PR을 만들었습니다.