Kscrash: KSThread verursacht einen Absturz beim Abrufen des Warteschlangennamens

Dies ist jetzt mein Absturz Nr. 1, kann sich bitte jemand dieses Problem ansehen? oder sollte ich meinen eigenen Zweig dieses Projekts machen?

Ich war die letzten Wochen zu sehr mit der Arbeit beschäftigt (neuer Job). Wenn jemand eine PR erstellt, füge ich sie normalerweise schnell zusammen!

Okay danke!

@ferrous777 Glück gehabt? Ich sehe diesen Absturz auch.

Ich kann nicht herausfinden, wie ich dieses Problem reproduzieren kann, aber es sieht so aus, als ob das dispatch_queue_ptr , das wir von thread_identifier_info_t.dispatch_qaddr erhalten, auf eine falsche Position zeigt. Ich habe gerade eine PR eingereicht, die den KSThread_Test wieder hinzufügt (https://github.com/kstenerud/KSCrash/pull/221), aber ich konnte nicht herausfinden, wie ich einen Test hinzufügen könnte, der uns dieses falsche Zeigerverhalten geben würde.

e8977a426ab3ef83939a1929c9c4743ae314bcd1 sollte dieses Problem beheben. Es wurde vor der Dereferenzierung nicht nach einem gültigen Zeiger gesucht. Dies ist auch mit 1.15.5 gekennzeichnet, und ich drücke auf Cocoapods.

@kstenerud Hallo Mann, ich habe deinen Commit überprüft
aber für diese Codezeile:
Dispatch_Queue_t* Dispatch_Queue_ptr = (Dispatch_Queue_t*)idInfo->Dispatch_qaddr;

Sind beim Bauen keine Fehler aufgetreten?

Habe den gleichen Fehler/Absturz, Version:

- 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

Protokolle:

[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]

Ich habe gerade den gleichen Absturz in KSCrash 1.15.18 gesehen:

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)

Der Absturz wird laut OP in dieser Zeile gemeldet:

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

Mit der CrashDoctor-Berichterstattung:

CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.

Die Anwendungsstatistik zeigt an, dass die App im Hintergrund war. Ich bin mir nicht sicher, ob das irgendwelche Auswirkungen auf diese Untersuchung hat!

Angesichts der Tatsache, dass idInfo in Zeile 79 über der Absturzstelle dereferenziert wird, schätze ich, dass es die Dereferenzierung dispatch_queue_ptr ist, die den Absturz verursacht. Das muss bedeuten, dass der ksmem_isMemoryReadable -Check von dispatch_queue_ptr in Zeile 80 nicht funktioniert?

Ich fürchte, ich verstehe noch nicht, wie ksmem_isMemoryReadable und seine Callees funktionieren, also stecke ich jetzt fest!

Hallo, ich habe das gleiche Problem in einer unserer Apps mit Sentry

KSCrash
0x100faa834
ksthread_getQueueNameKSCrash/Source/KSCrash/Recording/Tools/KSThread.c:87
KSCrash
0x100f925a0
updateThreadListKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:84
KSCrash
0x100f925a0
monitorCachedDataKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:137

Podfile.lock:

• KSCrash/Aufzeichnung (1.15.18):
  ...

Am besten

@oleksandrlysenkov kannst du den Absturz reproduzieren?

@Kmohamed Persönlich bin ich nicht in der Lage, auf meinen Geräten zu reproduzieren, aber ich erhalte jeden Tag eine Anmeldung bei Crashlytics über diesen Fehler und derzeit ist es der am häufigsten auftretende Absturz bei 2 meiner Projekte.

@oleksandrlysenkov eine Nebenfrage, warum Sie KSCrash und Crashlytics verwenden?

Mir ist gerade der Crash passiert! Es trat auf, als die App in den Vordergrund gestellt wurde. Die App stürzte sofort nach dem Vordergrund ab – die Benutzeroberfläche erschien kurz und verschwand dann, wie es für einen Absturz typisch ist.

Leider war es auf einem Debug-Build, für den ich keine Symbole habe, aber der Stack-Trace von Thread 0 und der abstürzende Thread zeigen, was die App gemacht hat:

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 Wir verwenden Crashlytics für die allgemeine Absturzprotokollierung zusammen mit Fabric und KSCrash innerhalb anderer Tools wie XCLogger

Wir sind von Crashlytics zu Sentry gewechselt. Alle Crashlatics-Quellen werden entfernt.

Der Absturz erscheint auch in XCode=>Organizer=>Crashes :: AppStore=> (a Released Version) => KSCrash ... Alles in Thread 3, alles in KSCrash ksthread_getQueueName verwiesen auf:

//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;
    }

Diese Ausgabe erscheint 10-20 Mal am Tag in unserem Sentry.

Es scheint, dass unsere Abstürze auftreten, nachdem der Garbadge Collector wegen unzureichendem Arbeitsspeicher beendet wurde: "Versuch, Garbage Pointer 0x16b717180 zu dereferenzieren."

Alle Geräte haben wenig Speicher zB: Speicher | Gesamt: 1,9 GB / Kostenlos: 55,8 MB / Verwendbar: 1,7 GB
Alle freien Speicher unter 100 MB, die meisten unter 50 MB

Und unsere Sentry-Zusatzprotokollierung mit Breadcrumbs zeigt Ereignisse in dieser Reihenfolge:

1. AppDelegate applicationDidEnterBackground () //Verursacht wegen Beendigung der OOM-App??
   manchmal: 1b. AppDelegate-Anwendung...
2. Es wurde versucht, Müll zu dereferenzieren => CRASH Gleicher Zeitstempel wie bei der letzten AppDelegate-Anwendung ...
   EXC_BAD_ACCESS
   Es wurde versucht, den Müllzeiger 0x16c0ab180 zu dereferenzieren.
   ... verschiedene Zeit dazwischen
3. Begrüßungsbildschirm

Manchmal (40-50 % aller Berichte) erscheint der Absturz auf: AppDelegate applicationWillResignActive. Dann muss der Benutzer die App zweimal neu starten oder ein Benutzer muss die App dreimal neu starten.

Zum Testen konnte ich die OOM-App-Beendigung durch eine zweite Vordergrund-App reproduzieren, die nur Speicher frisst, wie: https://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-called/18641099#18641099
Um die Zeit für die kritische Speichernutzung zu verkürzen, fordere ich zunächst die Hälfte des Gerätespeichers an:

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

Achtung, versuchen Sie dies auf dem Gerät, Ihr Simulator teilt möglicherweise den Speicher mit Ihrem Host-Mac.

@kstenerud Ich denke, dies ist eine akzeptable Lösung für diesen Absturz, bis jemand eine bessere # 281 findet

Der Absturz tritt immer noch auf, @kstenerud hoffe, dass Sie eine Lösung dafür finden können. Nach einer zusätzlichen Untersuchung fand ich heraus, dass dieser Absturz direkt nach dem Update von Version 1.15.16 auf 1.15.18 auftrat. Ich bin nicht so gut in ObjC, aber logischerweise verursachte diese Änderung den Absturz - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Link zu Details über den Absturz: http://crashes.to/s/149088e734b

@Kmohamed Ich bin mir nicht sicher, wie Ihre Pull-Anforderung das Problem lösen kann, das in meiner App auftritt. Ihre Änderung befindet sich in Zeile 94 von KSCrash.c, aber der Absturz erscheint in Zeile 87

Der einzige Weg, den Absturz zu vermeiden, ist meiner Meinung nach die Verwendung von Version 1.15.16 von KSCrash.

Ich habe einen Absturzbericht von iTunes Connect erhalten, der einige weitere Informationen enthält, die möglicherweise wertvoll sind. Mehr Infos als ich bisher gesehen habe.

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

ich auch
Hier gilt das gleiche!!

Das ist im Moment auch unser Nummer-eins-Crash.

Dies ist der erste Absturz meiner App

Dasselbe Problem hier. Bekomme diesen Absturz von Zeit zu Zeit über Sentry.

Einzelheiten:

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 Wenn Sie auf die neueste Version von sentry-cocoa 4.x.x aktualisieren, sollte dies dort behoben sein, da wir es in KSCrash selbst behoben haben.

@HazAT oh, danke für die Informationen! Das Aktualisieren von Sentry hat das Problem tatsächlich behoben.

@HazAT haben Sie dies behoben, indem Sie einfach die getQueueName-Funktionalität entfernt haben, oder haben Sie die Ursache für diesen Absturz gefunden? Wenn ja, würde es Ihnen etwas ausmachen, einen Pull-Request zu erstellen, damit dies für alle behoben wird?

@harp79 Wir haben es vorerst nur entfernt, da wir nicht die Zeit hatten, uns vollständig mit dem Problem zu befassen.

Wir verwenden Sentry-Cocoa 4.1.0 und sehen dieses Problem immer noch.

Läuft noch jemand darüber?

Ja, immer noch ein Problem. Unser Nummer eins (und aus irgendeinem Grund sechster) Crasher, wie von Crashlytics berichtet

Hier gilt das gleiche

Mein Verständnis ist, dass der Sentry 4.1.0 dies nicht mehr verwendet.