Kscrash: 큐 이름을 가져오는 동안 충돌을 일으키는 KSThread

이것은 지금 내 #1 충돌입니다. 누군가 이 문제를 볼 수 있습니까? 아니면 이 프로젝트의 내 자신의 지점을 만들어야 합니까?

지난 몇 주 동안 (새 직장) 일로 너무 바빴습니다. 누군가가 PR을 하면 나는 보통 그것들을 빠르게 병합합니다!

괜찮 감사!

@ferrous777 운이 좋습니까? 나는 또한이 충돌을보고 있습니다.

이 문제를 재현하는 방법을 알 수 없지만 thread_identifier_info_t.dispatch_qaddr dispatch_queue_ptr 가 가짜 위치를 가리키는 것 같습니다. 방금 KSThread_Test를 다시 추가하는 PR을 제출했지만(https://github.com/kstenerud/KSCrash/pull/221) 이 가짜 포인터 동작을 제공하는 테스트를 추가하는 방법을 알 수 없었습니다.

e8977a426ab3ef83939a1929c9c4743ae314bcd1이 이 문제를 해결해야 합니다. 역참조 전에 유효한 포인터를 확인하지 않았습니다. 이것은 또한 1.15.5로 태그가 지정되어 있으며 cocoapods로 추진 중입니다.

@kstenerud 안녕하세요, 이 커밋을 확인했습니다.
하지만 이 코드 줄의 경우:
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;

빌드할 때 오류가 발생하지 않았나요?

동일한 오류/충돌 발생, 버전:

- KSCrash/Core (1.15.18):
    - KSCrash/Reporting/Filters/Basic
  - KSCrash/Recording (1.15.18):
    - KSCrash/Recording/Tools (= 1.15.18)
  - KSCrash/Recording/Tools (1.15.18)
  - KSCrash/Reporting/Filters/Base (1.15.18):
    - KSCrash/Recording
  - KSCrash/Reporting/Filters/Basic (1.15.18):
    - KSCrash/Recording
    - KSCrash/Reporting/Filters/Base

로그:

[0  KSCrash                        0x102e22754 ksthread_getQueueName + 132
1  KSCrash                        0x102e22738 ksthread_getQueueName + 104
2  KSCrash                        0x102e0a4c0 monitorCachedData + 288
3  libsystem_pthread.dylib        0x185bac2b4 _pthread_body + 308
4  libsystem_pthread.dylib        0x185bac180 _pthread_body + 310
5  libsystem_pthread.dylib        0x185baab74 thread_start + 4]

방금 KSCrash 1.15.18에서 동일한 충돌을 보았습니다.

Thread 2 Crashed:
0   KSCrash                         0x0000000103052280 ksthread_getQueueName + 320128 (KSThread.c:87)
1   KSCrash                         0x0000000103052268 ksthread_getQueueName + 320104 (KSThread.c:80)
2   KSCrash                         0x000000010302b050 monitorCachedData + 159824 (KSCrashCachedData.c:139)
3   libsystem_pthread.dylib         0x0000000182d6c31c 0x182d6a000 + 8988 ( + 308)
4   libsystem_pthread.dylib         0x0000000182d6c1e8 0x182d6a000 + 8680 (_pthread_start + 312)

충돌은 OP에 따라 이 줄에 보고됩니다.

if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)

CrashDoctor 보고:

CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.

애플리케이션 통계는 앱이 백그라운드에 있음을 나타냅니다. 그것이 이 조사에 영향을 미칠지 잘 모르겠습니다!

idInfo 가 충돌 사이트 위의 라인 79에서 역참조된다는 점을 감안할 때 충돌을 일으키는 것은 dispatch_queue_ptr 역참조라고 생각합니다. 이것은 80행에 있는 dispatch_queue_ptr 의 ksmem_isMemoryReadable 검사가 제대로 작동하지 않는다는 것을 의미해야 합니까?

ksmem_isMemoryReadable 및 해당 호출 수신자가 아직 어떻게 작동하는지 이해하지 못해서 지금 막혔습니다!

안녕하세요, Sentry가 있는 앱 중 하나에 동일한 문제가 있습니다.

KSCrash
0x100faa834
ksthread_getQueueNameKSCrash/소스/KSCrash/녹음/도구/KSThread.c:87
KSCrash
0x100f925a0
updateThreadListKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:84
KSCrash
0x100f925a0
monitorCachedDataKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:137

Podfile.lock:

• KSCrash/녹음(1.15.18):
  ...

최상의

@oleksandrlysenkov 충돌을 재현할 수 있습니까?

@Kmohamed 개인적으로 내 장치에서 재현할 수 없지만 매일 이 버그에 대한 Crashlytics 로그인을 수신하고 현재 내 프로젝트 중 2개에서 가장 많이 나타나는 충돌입니다.

@oleksandrlysenkov 왜 KSCrash 및 Crashlytics를 사용하고 있습니까?

방금 나에게 충돌이 발생했습니다! 앱을 포그라운드로 전환할 때 발생했습니다. 앱이 포그라운드로 전환되는 즉시 충돌이 발생했습니다. 일반적인 충돌처럼 UI가 잠시 나타났다가 사라졌습니다.

불행히도 그것은 기호가 없는 디버그 빌드에 있었지만 스레드 0의 스택 추적과 충돌하는 스레드는 앱이 무엇을 하고 있었는지 보여줍니다.

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x00000000 at 0x000000016c2e7180
Crashed Thread:  2

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   QuartzCore                      0x00000001882086c8 CA::Layer::mark_context_changed+ 1222344 (CA::Transaction*) + 48
1   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
2   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
3   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
4   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
5   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
6   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
7   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
8   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
9   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
10  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
11  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
12  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
13  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
14  QuartzCore                      0x0000000188210078 CA::Layer::set_visible+ 1253496 (unsigned int) + 268
15  QuartzCore                      0x0000000188170790 CA::Context::set_layer+ 599952 (void const*) + 228
16  UIKit                           0x000000018dc57818 +[_UIContextBinder createContextForBindable:withSubstrate:] + 1080
17  UIKit                           0x000000018dc57380 -[_UIContextBinder _contextForBindable:] + 132
18  UIKit                           0x000000018dc22dc8 -[_UIContextBinder updateBindableOrderWithTest:force:] + 472
19  UIKit                           0x000000018dc22a14 -[_UIContextBinder createContextsWithTest:creationAction:] + 100
20  UIKit                           0x000000018dc25bb4 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:] + 784
21  UIKit                           0x000000018e8bb72c __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke + 296
22  UIKit                           0x000000018dc25268 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:] + 432
23  UIKit                           0x000000018e6a09b8 __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke + 220
24  UIKit                           0x000000018e7eeae8 _performActionsWithDelayForTransitionContext + 112
25  UIKit                           0x000000018dc24c88 -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:] + 248
26  UIKit                           0x000000018dc24624 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:] + 368
27  UIKit                           0x000000018dc623b0 -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 468
28  FrontBoardServices              0x0000000186888f24 __80-[FBSSceneImpl updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.362 + 212
29  libdispatch.dylib               0x000000018397cae4 _dispatch_client_callout + 16
30  libdispatch.dylib               0x00000001839b8b0c _dispatch_block_invoke_direct$VARIANT$armv81 + 216
31  FrontBoardServices              0x00000001868bc878 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 36
32  FrontBoardServices              0x00000001868bc51c -[FBSSerialQueue _performNext] + 404
33  FrontBoardServices              0x00000001868bcab8 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
34  CoreFoundation                  0x0000000184033404 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
35  CoreFoundation                  0x0000000184032c2c __CFRunLoopDoSources0 + 276
36  CoreFoundation                  0x000000018403079c __CFRunLoopRun + 1204
37  CoreFoundation                  0x0000000183f50da8 CFRunLoopRunSpecific + 552
38  GraphicsServices                0x0000000185f33020 GSEventRunModal + 100
39  UIKit                           0x000000018df3178c UIApplicationMain + 236
40  Charles                         0x00000001048e51b8 0x10471c000 + 1872312 (main + 76)
41  libdyld.dylib                   0x00000001839e1fc0 start + 4

Thread 2 Crashed:
0   KSCrash                         0x00000001053da84c 0x105358000 + 534604 (ksthread_getQueueName + 280)
1   KSCrash                         0x00000001053da828 0x105358000 + 534568 (ksthread_getQueueName + 244)
2   KSCrash                         0x0000000105397bb0 0x105358000 + 261040 (updateThreadList + 436)
3   KSCrash                         0x0000000105397710 0x105358000 + 259856 (monitorCachedData + 56)
4   libsystem_pthread.dylib         0x0000000183cb1220 _pthread_body + 272
5   libsystem_pthread.dylib         0x0000000183cb1110 _pthread_body + 0

Thread 3 name:  KSCrash Exception Handler (Secondary)
Thread 3:
0   libsystem_kernel.dylib          0x0000000183aefe08 mach_msg_trap + 8
1   libsystem_kernel.dylib          0x0000000183aefc80 mach_msg + 72
2   KSCrash                         0x00000001053a465c 0x105358000 + 312924 (handleExceptions + 268)
3   libsystem_pthread.dylib         0x0000000183cb1220 _pthread_body + 272
4   libsystem_pthread.dylib         0x0000000183cb1110 _pthread_body + 0

Thread 4 name:  KSCrash Exception Handler (Primary)
Thread 4:

@Kmohamed 우리는 XCGLogger와 같은 다른 도구 내부에서 Fabric 및 KSCrash와 함께 일반적인 충돌 로깅을 위해 Crashlytics를 사용합니다.

Crashlytics에서 Sentry로 이전했습니다. 모든 Crashlattics 소스가 제거됩니다.

충돌은 XCode=>Organizer=>Crashes :: AppStore=> (릴리즈된 버전) => KSCrash ...에도 나타납니다. 스레드 3의 모든 항목, KSCrash ksthread_getQueueName의 모든 항목은 다음을 참조합니다.

//thread_handle shouldn't be 0 also, because
    //identifier_info->dispatch_qaddr =  identifier_info->thread_handle + get_dispatchqueue_offset_from_proc(thread->task->bsd_info);
    if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
    {
        KSLOG_TRACE("This thread doesn't have a dispatch queue attached : %p", thread);
        return false;
    }

이 문제는 하루에 10-20번 Sentry에 나타납니다.

"가비지 포인터 0x16b717180을 역참조하려고 시도했습니다."

모든 장치의 메모리가 부족합니다. 예: 메모리 | 총: 1.9GB / 무료: 55.8MB / 사용 가능: 1.7GB
100MB 미만의 모든 여유 메모리 대부분 50MB 미만

그리고 우리의 Sentry 추가 Logging with Breadcrumbs는 이벤트를 순서대로 보여줍니다:

1. AppDelegate applicationDidEnterBackground () // OOM 앱 종료로 인해 발생 했습니까?
   때때로: 1b. AppDelegate 애플리케이션...
2. 가비지 역참조 시도 => CRASH 마지막 AppDelegate 애플리케이션과 동일한 타임스탬프...
   EXC_BAD_ACCESS
   가비지 포인터 0x16c0ab180을 역참조하려고 했습니다.
   ... 다양한 시간 사이
3. 스플래시 화면

때때로(모든 보고서의 40-50%) 충돌이 AppDelegate applicationWillResignActive에 나타납니다. 사용자가 앱을 두 번 다시 시작하거나 한 사용자가 앱을 세 번 다시 시작해야 하는 것보다.

테스트를 위해 다음과 같은 메모리를 먹는 두 번째 전경 앱으로 OOM 앱 종료를 재현할 수 있습니다.
중요한 메모리 사용 시간을 줄이려면 처음에 다음과 같이 장치 메모리의 절반을 요청합니다.

-(void)eatMemoryBigChunck
{
    NSLog(@"Eating eatMemoryBigChunck");
    unsigned long dinnerLength = 1024 * 1024 * 500;
...

장치에서 이것을 시도하십시오. 시뮬레이터가 호스트 Mac과 메모리를 공유할 수 있습니다.

@kstenerud 누군가가 더 나은 것을 찾을 때까지 이것이 이 충돌에 대한 수용 가능한 솔루션이라고 생각합니다. #281

충돌이 여전히 나타납니다. @kstenerud 는 해결 방법을 찾을 수 있기를 바랍니다. 추가 조사 후 해당 충돌이 버전 1.15.16에서 1.15.18로 업데이트한 직후에 나타났습니다. 나는 ObjC에 능숙하지 않지만 논리적으로 이 변경으로 인해 충돌이 나타납니다 - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
충돌에 대한 세부 정보 링크: http://crashes.to/s/149088e734b

@Kmohamed 귀하의 Pull 요청이 내 앱에 나타나는 문제를 어떻게 해결할 수 있는지 잘 모르겠습니다. 변경 사항은 KSCrash.c의 ​​94행에 있지만 충돌은 87행에 나타납니다.

그러나 충돌을 피하는 유일한 방법은 KSCrash 버전 1.15.16을 사용하는 것입니다.

중요할 수 있는 추가 정보가 포함된 iTunes Connect의 충돌 보고서가 있습니다. 내가 전에 본 것보다 더 많은 정보.

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000016d813180
VM Region Info: 0x16d813180 is not in any region.  Bytes after previous region: 553345  Bytes before following region: 20096
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      Stack                  000000016d690000-000000016d78c000 [ 1008K] rw-/rwx SM=PRV  thread 0
--->  GAP OF 0x8c000 BYTES
      Stack Guard            000000016d818000-000000016d81c000 [   16K] ---/rwx SM=NUL  

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread:  2

Thread 2 Crashed:
0   KSCrash                         0x0000000102d42280 ksthread_getQueueName + 128 (KSThread.c:87)
1   KSCrash                         0x0000000102d42268 ksthread_getQueueName + 104 (KSThread.c:80)
2   KSCrash                         0x0000000102d1b050 monitorCachedData + 288 (KSCrashCachedData.c:84)
3   libsystem_pthread.dylib         0x0000000181825220 _pthread_body + 272 (pthread.c:740)
4   libsystem_pthread.dylib         0x0000000181825110 _pthread_start + 292 (pthread.c:799)
5   libsystem_pthread.dylib         0x0000000181823b10 thread_start + 4

저도 요
여기도 마찬가지!!

이것은 또한 현재 우리의 1위 충돌입니다.

이것은 내 앱의 상위 1개 충돌입니다.

동일한 문제가 여기에 있습니다. Sentry를 통해 때때로 이 충돌을 수신합니다.

세부:

OS Version: iOS 11.3.1 (15E302)
Report Version: 104

Crashed Thread: 2

Application Specific Information:
Attempted to dereference garbage pointer 0x16dc8f180.

Thread 2 Crashed:
0   KSCrash                         0x10282dba8         ksthread_getQueueName (KSThread.c:87)
1   KSCrash                         0x102815a38         [inlined] updateThreadList (KSCrashCachedData.c:84)
2   KSCrash                         0x102815a38         monitorCachedData (KSCrashCachedData.c:137)
3   libsystem_pthread.dylib         0x305450220         <redacted>
4   libsystem_pthread.dylib         0x305450110         _pthread_start

@WingedDoom @xlbs-rm sentry-cocoa 4.x.x 의 최신 버전으로 업데이트하는 경우 KSCrash에서 직접 수정했기 때문에 이 부분에서 수정해야 합니다.

@HazAT 오, 정보 감사합니다! 센트리를 업데이트하면 실제로 문제가 해결되었습니다.

@HazAT getQueueName 기능을 제거하여 이 문제를 해결했습니까? 아니면 이 충돌의 근본 원인을 찾았습니까? 그렇다면 모든 사람이 이 문제를 해결할 수 있도록 Pull Request를 생성하시겠습니까?

@harp79 문제를 완전히 파헤칠 시간이 없었기 때문에 지금은 삭제했습니다.

Sentry-Cocoa 4.1.0을 사용하고 있으며 이 문제가 계속 발생합니다.

아직도 이것을 가로질러 달리는 사람이 있습니까?

네, 여전히 문제입니다. Crashlytics에서 보고한 1위(어떤 이유로든 6위) 크래시

여기도 마찬가지

내 이해는 Sentry 4.1.0이 더 이상 이것을 사용하지 않는다는 것입니다.