iOS Absturzberichte: Atos funktioniert nicht wie erwartet

Ich bin auf der Suche auf einen Absturz-Bericht von Apple

Hardware Model:      iPhone4,1
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-11-18 16:03:44.951 -0600
OS Version:      iOS 6.0.1 (10A523)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x352925b0 objc_msgSend + 16
1   MYAPP                           0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42
2   MYAPP                           0x0004fb26 -[MyImageTask didReceiveImage:] + 98
3   Foundation                      0x361ac8e8 __NSThreadPerformPerform
4   CoreFoundation                  0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
5   CoreFoundation                  0x3b37cee4 __CFRunLoopDoSources0
6   CoreFoundation                  0x3b37bcb2 __CFRunLoopRun
7   CoreFoundation                  0x3b2eeeb8 CFRunLoopRunSpecific
8   CoreFoundation                  0x3b2eed44 CFRunLoopRunInMode
9   GraphicsServices                0x396bc2e6 GSEventRunModal
10  UIKit                           0x3452e2f4 UIApplicationMain
11  MYAPP                           0x0004934a main + 70
12  MYAPP                           0x000492fc start + 36

Das komische ist, wenn ich mit atos zu Suche die Zeile des Codes entspricht, Anschrift Standorte 0x0006573a und 0x0004fb26 ich bekomme ganz anderes Spiel. Die atos-Ausgang ist auch nicht von der gleichen Klasse, die erwähnt wird in der crash-log (MyViewController, MyImageTask). Stattdessen atos Punkte die mich völlig gutartig Zeilen code in einer völlig anderen Klasse. Ich überprüfte nochmal, ich arbeite mit der genauen dSYM und IPA, die ich an Apple gesendet.

Mein atos Befehl

/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26

Gleiche Ergebnis mit /usr/bin/atos und für armv7s.

Hat sonst noch jemand erlebt dieses Problem? Können Sie bitte beraten? Danke.

InformationsquelleAutor der Frage George Burdell | 2012-11-26

  1. 89

    Haben Sie zur Berechnung der Adresse verwenden, mit atos, kann man nicht einfach die benutzen, die im stacktrace.

    symbol address = slide + stack address - load address

    1. Den slide Wert ist der Wert der vmaddr im LC_SEGMENT cmd (Meist ist dies 0x1000). Führen Sie die folgenden, um es zu bekommen:

      otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"

      Ersetzen ARCHITECTURE mit der eigentlichen Architektur der crash-Bericht zeigt, z.B. armv7.
      Ersetzen APP_BUNDLE/APP_EXECUTABLE mit dem Pfad zur eigentlichen Programmdatei.

    2. Den stack address ist der hex-Wert aus der crash-Bericht.

    3. Den load address werden kann, ist die erste Adresse zeigt, in die Binary Images Sektion ganz vorne von der Linie, die enthält die ausführbare Datei. (Normalerweise der erste Eintrag).

    Da in der Vergangenheit Wert der slide war gleich dem Wert der load address dies immer geklappt. Aber da Apple eingeführt Address space layout randomization Anfang an mit iOS 4.3 (in verschiedenen Variationen), die apps laden-Adresse ist randomisiert aus Gründen der Sicherheit.

    InformationsquelleAutor der Antwort Kerni

  2. 95

    Einfachere alternative: Sie können die atos -l flag zu machen, tun die Mathematik für Sie.

    Sagen du hast die folgende Zeile in der crash-log, dass Sie wollen symbolicate:

    5   MyApp                   0x0044e89a 0x29000 + 4348058

    Die erste hex-Zahl ist die stack-Adresse, und die zweite hex-Zahl ist die Adresse laden. Können Sie ignorieren die Letzte Zahl. Sie brauchen nicht zu befürchten, dia-Adressen.

    Zu symbolicate, tun Sie den folgenden:

    atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a

    Wenn Sie nicht finden können, Ihre Anwendung.app/MyApp-Datei umbenennen '.ipa' Datei '.zip', entpacken Sie es, und es werden in den Payload Ordner.

    Und wenn Sie nicht sicher sind, welche Architektur zu verwenden (zum Beispiel, armv7 oder armv7s), Blättern Sie zu der "Binäre Bilder" Teil der crash-Datei, können Sie finden es dort.

    Cheers

    InformationsquelleAutor der Antwort Chris

  3. 11

    Verwenden Sie einfach dwarfdump:

    dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'

    Keine Notwendigkeit zu tun, die keine Berechnungen überhaupt.

    (Aus Symbol abrufen anhand der Adresse (symbolicating Binär -, iOS-build)).

    InformationsquelleAutor der Antwort CpnCrunch

  4. 3

    Für wen, dass bestimmte Zeiten nicht den Wert für die Load-Adresse wie folgt:

    Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
    0   CoreFoundation                      0x2c3084b7 <redacted> + 150
    1   libobjc.A.dylib                     0x39abec8b objc_exception_throw + 38
    2   CoreFoundation                      0x2c21cc35 CFRunLoopRemoveTimer + 0
    3   AppName                             0x0005a7db AppName + 272347

    Habe ich ein einfaches bash, um mir zu helfen debug:

    #! /bin/bash
read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7

    Es gerade liest den Pfad für die app, der app-name, die stack-Adresse, und der Wert nach dem " + " - signal (dezimal-Wert) und dann den Wert für load-Adresse laufen atos Befehl.

    InformationsquelleAutor der Antwort DenninDalke

Schreibe einen Kommentar