Rapports de crash iOS: atos ne fonctionnant pas comme prévu

Question

Je suis à la recherche d'un rapport de crash fourni par 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

Le plus drôle, c'est quand j'utilise atos à la recherche de la ligne de code qui correspond à l'adresse endroits 0x0006573a et 0x0004fb26 je reçois complètement différente match. Atos de sortie n'est même pas de la même classe qui est mentionné dans le rapport de crash (MyViewController, MyImageTask). Au lieu d'atos points moi de totalement bénigne de lignes de code dans un complètement indépendant de la classe. J'ai vérifié encore une fois que je suis en train de travailler avec l'exacte dSYM et de l'api, que j'ai soumis à Apple.

Mon atos commande

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

Même résultat avec la commande /usr/bin/atos et pour armv7s.

Quelqu'un d'autre a rencontré ce problème? Pouvez-vous me conseiller? Merci.

Answer 1

Une solution plus simple: vous pouvez utiliser l' atos -l drapeau d'en faire le calcul pour vous.

Dites que vous avez la ligne suivante dans votre crash journal que vous souhaitez symbolicate:

5   MyApp                   0x0044e89a 0x29000 + 4348058

Le premier nombre hexadécimal est la pile l'adresse, et le second nombre hexadécimal est l'adresse de chargement. Vous pouvez ignorer le dernier numéro. Vous n'avez pas besoin de vous soucier de glisser les adresses.

Pour symbolicate, procédez de la manière suivante:

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

Si vous ne trouvez pas votre MyApp.app/MyApp fichier, renommez votre".ipa' fichier '.fichier zip, décompressez-le, et il sera en Charge du dossier.

Et si vous n'êtes pas sûr de l'architecture à utiliser (par exemple, armv7 ou armv7s), faites défiler jusqu'à la "Images Binaires" une partie de l'écrasement du fichier et vous pouvez le trouver là.

Cheers

Answer 2

Vous devez calculer l'adresse à utiliser avec atos, vous ne pouvez pas simplement utiliser l'une dans la stacktrace.

symbol address = slide + stack address - load address

1. L' slide de la valeur est la valeur de vmaddr en LC_SEGMENT cmd (la Plupart du temps il est 0x1000). Exécuter les opérations suivantes:

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

   Remplacer ARCHITECTURE avec l'architecture même du crash rapport montre, par exemple, armv7. Remplacer APP_BUNDLE/APP_EXECUTABLE avec le chemin d'accès au réel de l'exécutable.

2. L' stack address la valeur hexadécimale du rapport de crash.

3. L' load address peut être est la première adresse figurant dans l' Binary Images section très à l'avant de la ligne qui contient l'exécutable. (Généralement la première entrée).

Depuis, dans le passé, la valeur de l' slide a été égale à la valeur de l' load address - ce toujours travaillé. Mais depuis que Apple a introduit Address space layout randomization début avec iOS 4.3 (en variations), les applications de chargement de l'adresse est aléatoire pour des raisons de sécurité.

Answer 3

Il suffit d'utiliser dwarfdump:

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

Pas besoin de faire des calculs du tout.

(De Get symbole par adresse (symbolisant le binaire, la version iOS) ).