CrashReports richtig auswerten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • CrashReports richtig auswerten

    Hallo,

    ein Nutzer meiner Mac App berichtet von verschiedenen Abstürzen. Er war so nett mir die zugehörigen CrashLogs zu senden, aber ich werde daraus nicht wirklich schlau. Die Suche bei Google bringt schnell zahlreiche Tipps wie man mehr Informationen bis hin zur genauen Zeile im Code bekommt. Aber: Ich bekomme das nicht hin.

    Das Archive der im App Store veröffentlichten Version habe ich noch. .app und .dSYM sind also vorhanden.


    Erster Schritt ist demnach ein "Symbolicate" des CrashLogs. Klingt gut, funktioniert aber nicht.
    1. Man soll die CrashLogs in den Xcode Organizer importieren. Nach dem Import werden diese dort aber leider nicht sichtbar. Ich habe die Liste der Logs gelöscht und nach dem Import ist die Liste immer noch leer. Keine Fehlermeldung, nicht... (Xcode 5)

    2. Verschiedene Seiten beschreiben wie man das Symbolicate im Terminal manuell ausführen kann (z.B. hier). Das funktioniert auch, nur sieht das Log anschließend genau aus wie vorher. Wie genau sollte sich das Symbolicate auswirken?

    3. Der folgende Aufruf sollte dann Details zeigen:

    Quellcode

    1. atos o /path/to/MyApp.app/MyApp SPEICHERADRESSE


    Der Aufruf liefert bei mir aber einfach SPEICHERADRESSE zurück. Das Ganze sieht also so aus:


    atos o /path/to/MyApp.app/MyApp SPEICHERADRESSE
    SPEICHERADRESSE

    atos o /path/to/MyApp.app/MyApp 0x103690000
    0x103690000

    ...



    Der CrashReport sieht dabei so aus:

    Process: MyApp [6324]
    Path: /Applications/MyApp.app/Contents/MacOS/MyApp
    Identifier: my.app.MyApp
    Version: 1.1 (1.1)
    App Item ID: 634892482
    App External ID: 15806104
    Code Type: X86-64 (Native)
    Parent Process: launchd [556]
    User ID: 501

    Date/Time: 2013-09-23 14:20:18.561 +0200
    OS Version: Mac OS X 10.8.5 (12F37)
    Report Version: 10

    Crashed Thread: 0 Dispatch queue: com.apple.main-thread

    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: EXC_I386_GPFLT

    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0 libobjc.A.dylib 0x00007fff8395c36e objc_retain + 14
    1 my.app.MyApp 0x000000010371b529 0x103690000 + 570665
    2 com.apple.AppKit 0x00007fff88c0551f -[NSApplication sendEvent:] + 5468
    3 com.apple.AppKit 0x00007fff88b1b21a -[NSApplication run] + 636
    4 com.apple.AppKit 0x00007fff88abfbd6 NSApplicationMain + 869
    5 my.app.MyApp 0x0000000103695a75 0x103690000 + 23157
    6 my.app.MyApp 0x00000001036923b4 0x103690000 + 9140

    ...



    Für jeden Tipp wie genau ich hieraus schlauer werde bin ich wirklich Dankbar!
  • Agenor schrieb:

    Hallo,

    ein Nutzer meiner Mac App berichtet von verschiedenen Abstürzen. Er war so nett mir die zugehörigen CrashLogs zu senden, aber ich werde daraus nicht wirklich schlau. Die Suche bei Google bringt schnell zahlreiche Tipps wie man mehr Informationen bis hin zur genauen Zeile im Code bekommt. Aber: Ich bekomme das nicht hin.

    Das Archive der im App Store veröffentlichten Version habe ich noch. .app und .dSYM sind also vorhanden.


    Erster Schritt ist demnach ein "Symbolicate" des CrashLogs. Klingt gut, funktioniert aber nicht.

    Ich wußte gar nicht dass es das geben könnte.


    Process: MyApp [6324]
    Path: /Applications/MyApp.app/Contents/MacOS/MyApp
    Identifier: my.app.MyApp
    Version: 1.1 (1.1)
    App Item ID: 634892482
    App External ID: 15806104
    Code Type: X86-64 (Native)
    Parent Process: launchd [556]
    User ID: 501

    Date/Time: 2013-09-23 14:20:18.561 +0200
    OS Version: Mac OS X 10.8.5 (12F37)
    Report Version: 10

    Crashed Thread: 0 Dispatch queue: com.apple.main-thread

    bis hier keine wichtigen, neuen Erkenntnisse


    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: EXC_I386_GPFLT

    Das heißt (SIGSEGV) dass der Prozeß einen SIGSEGV bekomnen hat. Quasi ein automatischer kill -SEGV. Das passiert wenn man versucht auf eine Speicheradresse zuzugreifen, wo kein (virtueller) Speicher existiert. D.h. der Pointer zeigt ins "Nirwana".



    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0 libobjc.A.dylib 0x00007fff8395c36e objc_retain + 14
    1 my.app.MyApp 0x000000010371b529 0x103690000 + 570665
    2 com.apple.AppKit 0x00007fff88c0551f -[NSApplication sendEvent:] + 5468

    Da haben wir schon den Übeltäter. Zumindest scheint es so. Und zwar versucht der sendEvent einem Pointer ein [objPointer retain] zu schicken was schief geht, weil das Objekt schon aus dem Speicher verschwunden ist.
    Das hilft aber nicht viel weiter weil:

    3 com.apple.AppKit 0x00007fff88b1b21a -[NSApplication run] + 636
    4 com.apple.AppKit 0x00007fff88abfbd6 NSApplicationMain + 869
    5 my.app.MyApp 0x0000000103695a75 0x103690000 + 23157
    6 my.app.MyApp 0x00000001036923b4 0x103690000 + 9140

    ...

    ... hier offensichtlich etwas innerhalb vom AppKit passiert. D.h. die genaue Codezeile zu kennen hilft da überhaupt nichts, weil man den Sourcecode nicht kennt und dort auch nicht die wirkliche Ursache zu finden ist.

    Aber wo werden Events hingeschickt? An NSWindows, NSViews und NSViews. Vermutlich ist das ein Event das an ein nicht mehr vorhandenes NSWindow gehen soll.

    Das alles öffnet schon Möglichkeiten für Spekulationen:
    * gibts irgendwo einen [window release]?
    * ist das Window auf releaseWhenClosed gestellt, wird aber dennoch benutzt?
    * was sagt der Debugger bei "NSZombieEnabled"?

    Aber wie bei jedem Bug ist es besonders wichtig ein Szenario zu finden, wie man den Bug reproduzieren kann. Also z.B: Fenster öffnen, wieder schließen, anderes Öffnen, und dann Menü "FIles" öffnen. Oder so.

    Hoffe das hilft ein bischen weiter.
  • Damit atos funktioniert, muss sich das dSYM-Bundle im gleichen Verzeichnis wie das App-Bundle befinden. Vielleicht liegt es ja daran. Das Logfile selbst wird von atos nicht angefasst (das weiß ja auch gar nichts von dessen Existenz ;-). Das Ergebnis wird direkt im Terminal angezeigt:

    Quellcode

    1. % atos -o /BuildProducts/Release/Sketch.app/Contents/MacOS/Sketch -arch x86_64 -l 0x10acde000 0x10acea1d3 0x10ace4bea 0x10ace4b7a
    2. -[SKTGraphicView drawRect:] (in Sketch) (SKTGraphicView.m:445)
    3. -[SKTGraphic drawHandlesInView:] (in Sketch) (NSGeometry.h:110)
    4. -[SKTGraphic drawHandleInView:atPoint:] (in Sketch) (SKTGraphic.m:490)
  • plasmatron schrieb:

    /BuildProducts/Release/Sketch.app/Contents/MacOS/Sketch -arch x86_64 -l 0x10acde000 0x10acea1d3 0x10ace4bea 0x10ace4b7a


    Das wäre genau was ich suche, aber es funktioniert nicht. Ich habe noch genau das Archive von der App-Version die aktuell im Store ist.

    Quellcode

    1. MeineApp.xarchive
    2. dSYMs
    3. MeineApp.app.dSYM
    4. Products
    5. Applications
    6. MeineApp.app


    Ich habe also MeineApp.app.dSYM und MeineApp.app in ein gemeinsames Verzeichnis kopiert. Dort rufe ich im Terminal atos auf:

    Quellcode

    1. atos -o MeineApp.app/Contents/MacOS/MeineApp SPEICHERADRESSE
    2. Ausgabe:
    3. SPEICHERADRESSE


    Als Antwort auf die Frage "Was verbirgt sich hinter "SPEICHERADRESSE" erhalte ich also "SPEICHERADRESSE".

    Ich würde mir natürlich auch so etwas wie -[SKTGraphicView drawRect:] erhoffen. Wie komme ich daran?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Agenor ()

  • gar nicht, weil das in Deinem Crash-Report nicht vorkommt. Siehe meine Erläuterungen oben.


    Wie meinst du das? Dass bei mir nicht genau "-[SKTGraphicView drawRect...]" ausgegeben wird ist klar. Aber ich würde so etwas wie -[MeineKlasse machwas...] erwarten. Oder sehe ich das falsch? Einträge im Crash Log wie "my.app.MyApp 0x000000010371b529 0x103690000 + 570665" sagen doch, dass an der Stelle "0x000000010371b529 0x103690000 + 570665" in meinem Code irgendwas gemacht wurde, oder nicht? Auch wenn der Absturz dann im App Kit passiert ist, wäre es zumindest schon hilfreich zu wissen welche Stell in meinem Code zuletzt betroffen/aktiv war.

    Was ist in diesem Beispiel übrigens die korrekte Speicheradresse für atos?

    Quellcode

    1. "my.app.MyApp 0x000000010371b529 0x103690000 + 570665"


    0x000000010371b529 0x103690000 + 570665?
    0x000000010371b529?
    0x103690000?
    0x103690000 + 570665?


    Gib mal den Offset mit an:
    atos -o MeineApp.app/Contents/MacOS/MeineApp 0x103690000 + 570665


    Das funktioniert leider auch nicht:


    atos -o MeineApp.app/Contents/MacOS/MeineApp 0x103690000 + 570665

    Ausgabe:
    0x103690000
    +
    0x00570665 (in MeienApp)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Agenor ()

  • Also die korrekte Angabe ist 0x000000010371b529 (0x103690000 + 570665 = 0x000000010371b529). Das mit dem Offset war Unsinn -- mir war so, dass man den Offset angeben musste.

    Was steht denn im Crashlog in der "Binary Images"-Sektion in der ersten Spalte bei der Zeile mit deinem Bundle Identifier -- etwas anderes als 0x100000000? Wenn nicht, dann diesen Wert bei atos mit dem -l Flag mit angeben.
  • Chris schrieb:

    Ich geb bei atos -o gleich das dsym an.


    Das habe ich auch schon versucht, leider ohne Erfolg. Hast du ein Beispiel für einen korrekten Aufruf?


    Ich habe es in der Zwischenzeit geschafft das CrashLog richtig zu "Symbolisieren". Scheinbar ist das Tool symbolicatecrash von Xcode nur für iOS Crash Reports geeignet, es gibt aber auch eine Version für Mac Crash Reports. Damit hat es prima funktioniert:


    Crashed Thread: 0 Dispatch queue: com.apple.main-thread

    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: EXC_I386_GPFLT

    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0 libobjc.A.dylib 0x00007fff8395c36e objc_retain + 14
    1 my.app.MyApp 0x000000010371b529 0x103690000 + 570665
    2 com.apple.AppKit 0x00007fff88c0551f -[NSApplication sendEvent:] + 5468
    3 com.apple.AppKit 0x00007fff88b1b21a -[NSApplication run] + 636
    4 com.apple.AppKit 0x00007fff88abfbd6 NSApplicationMain + 869
    5 my.app.MyApp 0x0000000103695a75 0x103690000 + 23157
    6 my.app.MyApp 0x00000001036923b4 0x103690000 + 9140


    Wird zu


    Crashed Thread: 0 Dispatch queue: com.apple.main-thread

    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: EXC_I386_GPFLT

    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0 libobjc.A.dylib 0x00007fff8395c36e objc_retain + 14
    1 my.app.MyApp 0x000000010371b529 -[MyView mouseEntered:] (MyView.m:122)
    2 com.apple.AppKit 0x00007fff88c0551f -[NSApplication sendEvent:] + 5468
    3 com.apple.AppKit 0x00007fff88b1b21a -[NSApplication run] + 636
    4 com.apple.AppKit 0x00007fff88abfbd6 NSApplicationMain + 869
    5 my.app.MyApp 0x0000000103695a75 main (receipt.h:3457)
    6 my.app.MyApp 0x00000001036923b4 start + 52


    Damit weiß ich also, dass [MyView mouseEntered:] der letzte Code von mir ist, der vor dem Crash ausgeführt wurde. Welche Information könnte mir atos nun noch liefern?

    Hierzu noch eine Frage:
    SIGSEGV gibt ja an, dass ein Zugriff auf eine falsche Speicheradresse stattgefunden hat. Vermutlich wurde also auf ein Objekt zugegriffen, dass es gar nicht (mehr) gibt. Richtig? Muss ich den Report so verstehen, dass es das Objekt vom Typ "MyView" nicht gab, oder das MyView in der Methode mouseEntered: versucht hat auf ein nicht existierendes Objekt zuzugreifen?
  • Zitat von »Chris«
    Ich geb bei atos -o gleich das dsym an.


    Das habe ich auch schon versucht, leider ohne Erfolg. Hast du ein Beispiel für einen korrekten Aufruf?


    Frisch aus dem Terminal kopiert.

    Thread 11 Crashed:
    0 libsystem_kernel.dylib 0x00007fff8a0a7ce2 __pthread_kill + 10
    1 libsystem_c.dylib 0x00007fff8d5527d2 pthread_kill + 95
    2 libsystem_c.dylib 0x00007fff8d543a7a abort + 143
    3 libc++abi.dylib 0x00007fff877397bc abort_message + 214
    4 libc++abi.dylib 0x00007fff87736fcf default_terminate() + 28
    5 libobjc.A.dylib 0x00007fff8812d1b9 _objc_terminate + 94
    6 libc++abi.dylib 0x00007fff87737001 safe_handler_caller(void (*)()) + 11
    7 libc++abi.dylib 0x00007fff8773705c std::terminate() + 16
    8 libc++abi.dylib 0x00007fff87738152 __cxa_throw + 114
    9 libobjc.A.dylib 0x00007fff8812ce7a objc_exception_throw + 327
    10 com.apple.CoreFoundation 0x00007fff91802d8a +[NSException raise:format:arguments:] + 106
    11 com.apple.CoreFoundation 0x00007fff91802d14 +[NSException raise:format:] + 116
    12 com.apple.Foundation 0x00007fff8a13825e -[NSString stringByReplacingOccurrencesOfString:withString:options:range:] + 87
    13 de.chris.app 0x00000001000543c4 0x100000000 + 345028
    14 de.chris.app 0x00000001000549ee 0x100000000 + 346606
    15 de.chris.app 0x000000010005c8ad 0x100000000 + 379053
    16 com.apple.Foundation 0x00007fff8a10c72a -[NSThread main] + 68
    17 com.apple.Foundation 0x00007fff8a10c6a2 __NSThread__main__ + 1575
    18 libsystem_c.dylib 0x00007fff8d5508bf _pthread_start + 335
    19 libsystem_c.dylib 0x00007fff8d553b75 thread_start + 13

    nathan:2.4.1 chris$ atos -o ChrisApp.app.dSYM/Contents/Resources/DWARF/ChrisApp 0x00000001000543c4
    -[Class preparePostCommand:parameters:] (in ChrisApp) (Datei.m:1783)



    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.
  • nathan:2.4.1 chris$ atos -o ChrisApp.app.dSYM/Contents/Resources/DWARF/ChrisApp 0x00000001000543c4
    -[Class preparePostCommand:parameters:] (in ChrisApp) (Datei.m:1783)


    Auch das liefert bei mir genau das Gleiche wie zuvor: Ausgabe = Eingabe...

    Für meinen konkreten Fehlerbericht wäre jetzt noch die letzte Frage wichtig:

    SIGSEGV gibt ja an, dass ein Zugriff auf eine falsche Speicheradresse stattgefunden hat. Vermutlich wurde also auf ein Objekt zugegriffen, dass es gar nicht (mehr) gibt. Richtig? Muss ich den Report so verstehen, dass es das Objekt vom Typ "MyView" nicht gab, oder das MyView in der Methode mouseEntered: versucht hat auf ein nicht existierendes Objekt zuzugreifen?