Rapports d'incidents iOS: atos ne fonctionne pas comme prévu

Je regarde un rapport d'accident 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 

La chose amusante est quand j'utilise atos pour searchr la ligne de code qui correspond aux locations d'adresse 0x0006573a et 0x0004fb26 je reçois une correspondance complètement différente. La sortie atos n'est même pas de la même class que celle mentionnée dans le journal de crash (MyViewController, MyImageTask). Au lieu de cela, atos me pointe vers des lignes de code totalement inoffensives dans une class complètement indépendante. J'ai vérifié à nouveau que je travaillais avec le dSYM exact et IPA que j'ai soumis à Apple.

Ma command atos

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

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

Est-ce que quelqu'un d'autre a rencontré ce problème? Pouvez-vous s'il vous plaît conseiller? Merci.

    Vous devez calculer l'adresse à utiliser avec atos, vous ne pouvez pas utiliser celui de la stack.

     symbol address = slide + stack address - load address 
    1. La valeur de la slide est la valeur de vmaddr dans LC_SEGMENT cmd (Généralement c'est 0x1000 ). Exécutez ce qui suit pour l'get:

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

      Remplacez ARCHITECTURE par l'architecture réelle armv7 par le rapport d' armv7 , par exemple armv7 . Remplacez APP_BUNDLE/APP_EXECUTABLE par le path d'access à l'exécutable actuel.

    2. L' stack address est la valeur hexadécimale du rapport d'erreur.

    3. L' load address peut être la première adresse figurant dans la section Binary Images au tout début de la ligne qui contient votre exécutable. (Habituellement, la première input).

    Puisque dans le passé la valeur de la slide était égale à la valeur de l' load address cela a toujours fonctionné. Mais depuis qu'Apple a introduit la randomisation de disposition d'espace d'adressage commençant avec iOS 4.3 (dans différentes versions), l'adresse de chargement des applications est randomisée pour des raisons de security.

    Une alternative plus simple: vous pouvez utiliser le drapeau atos -l pour faire les calculs pour vous.

    Supposons que vous ayez la ligne suivante dans votre journal de crash que vous voulez symboliser:

     5 MyApp 0x0044e89a 0x29000 + 4348058 

    Le premier nombre hexadécimal est l'adresse de la stack, et le second nombre hexadécimal est l'adresse de chargement. Vous pouvez ignorer le dernier numéro. Vous n'avez pas non plus besoin de vous soucier des adresses de diapositives.

    Pour symboliser, faites ce qui suit:

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

    Si vous ne trouvez pas votre file MyApp.app/MyApp, renommez votre file '.ipa' en '.zip', décompressez-le, et ce sera dans le dossier Payload.

    Et si vous n'êtes pas sûr de l'architecture à utiliser (par exemple, armv7 ou armv7s), faites défiler jusqu'à la partie «Images binarys» du file de crash et vous pouvez le find là.

    À votre santé

    Utilisez simplement dwarfdump:

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

    Pas besoin de faire des calculs du tout.

    (A partir du symbole Obtenir par adresse (symbole binary, construction iOS) ).

    Pour qui certains moments n'ont pas la valeur pour Load Address comme ceci:

     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 

    J'ai créé un bash simple pour m'aider à déboguer:

     #! /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 

    Il lit simplement le path de l'application, le nom de l'application, l'adresse de la stack et la valeur après le signal "+" (la valeur décimale), puis trouve la valeur de l'adresse de chargement pour exécuter la command atos.