Atos et Dwarfdump ne symboliseront pas mon adresse

J'ai utilisé la suite de l'arithmétique à la figure:

slide + stack address - load address = symbol address

et

stack address est la valeur hexadécimale que je reçois de mon vidage de pile rapport de crash (pas un .crash fichier, il suffit de le vidage de pile).

et

slide est le vmaddr de la LC_SEGMENT cmd lors de l'exécution de otool -arch armv7 -l APP_BINARY_PATH. Mine termine généralement par 0x00001000.

et

load address est la pièce compliquée. C'est en fait la différence entre le bas de la pile l'adresse de la thread principale et la PREMIÈRE adresse de la partie de mon fichier binaire qui contient des symboles lors de l'exécution de dwarfdump --arch armv7 --all DSYM_BINARY_PATH. C'est tout simplement la symbolique de l'adresse de l' main fonction. Donc, si vos résultats les plus crash adresse est 0x8000 et votre principale fonction symbolique de l'adresse est 0x2000 alors votre load address est 0x6000.

Maintenant, avec TOUTES ces pièces, je peux calculer le symbole de l'adresse et placez-la dans atos ou dwarfdump: dwarfdump --lookup SYM_ADDR --arch armv7 APP_BINARY_PATH.

Exemple de la décharge (vous pouvez voir que le load address était 0x00003af4):

----------------------------------------------------------------------

Fichier: /Users/utilisateur/Bureau/MyApp.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/NAIN/MyApp (armv7)

----------------------------------------------------------------------

0x00000024: [0x00003af4 - 0x00003b4e) principaux

0x00000098: [0x00003b50 - 0x00003d8c) -[MyAppDelegate application: didFinishLaunchingWithOptions:]

... le reste de la décharge

La partie la plus difficile a été de réaliser que l'un des 2 bibliothèques statiques j'avais compris a leurs symboles dépouillé avant d'être le lien de mon application binaire! Qui a laissé un ÉNORME écart de symbole adresses alors je n'en ai terminé avec les deux tiers des symboles j'avais besoin dans mon dSYM.

Assurez-vous d'avoir les options suivantes à régler sur NON dans vos bibliothèques statiques xcode projet, de sorte que, lorsque vous vous connectez, vous pouvez tirer dans les symboles de votre application binaire (qui peut par la suite être dépouillé): COPY_PHASE_STRIPDEAD_CODE_STRIPPINGet STRIP_INSTALLED_PRODUCT.

Maintenant, vous pouvez demander, "que dois-je faire si le vidage de pile ne comprend pas la fonction principale, car il n'est pas sur le thread principal, de sorte que je ne peux pas obtenir la fonction principale de la pile d'adresse?". Pour que je lui aurais répondu, "je n'ai pas un putain la moindre idée!". Juste croiser les doigts et espérons que vous pouvez obtenir une trace de la pile qui comprend le symbole de l'adresse ou de l'utilisation d'un crash système de rapports qui imite Apple crash journaux, comme PLCrashReporter.

[MODIFIER 26 Mai 2013] -

Il a été porté à mon attention que les load address est vraiment l'adresse de l'mach-o binaire. Si ce que j'ai décrit ci-dessus peut souvent - ce n'est pas vraiment correct. Ceci peut être obtenu par le RAPPORT de CRASH, toutefois, le point de cette réponse a été de fournir les symboles d'un crash lorsque vous ne disposez pas d'un rapport de crash. La meilleure façon que j'en suis venu à comprendre la load address quand on veut symbolicate est de s'assurer que je me connecte le load address avec le stack addresses.

J'ai personnellement créé un système d'enregistrement des accidents (pas les rapports de plantage) et de les avoir envoyés à un compartiment S3 où je peux les récupérer plus tard pour le débogage. Lorsque je démarre mon application que je cache la slidele load address et la main function address pour une utilisation si mon application se bloque et j'ai envoyer le stack addresses.

REMARQUE: le dyld fonctions utilisent #include <mach-o/dyld.h>

slide = l'adresse retournée par _dyld_get_image_vmaddr_slide(0)

load address = l'adresse retournée par _dyld_get_image_header(0)

main function address = la dernière adresse [NSThread callStackReturnAddresses] quand
appelé sur le thread principal

Au crash de temps, je suis certain de vous connecter [NSThread callStackReturnAddresses] et [NSThread callStackSymbols] ainsi que l'architecture qui peut être récupérer par le fait d'avoir cette méthode:

- (NSString*) arch
{
    NSString* arch =
#ifdef _ARM_ARCH_7
        @"armv7";
#elif defined (_ARM_ARCH_6)
        @"armv6";
#else
        nil;
#endif

    return arch;
}

Je ne sais pas encore comment différencier entre armv7 et armv7s.

Si cela peut aider dans le futur. J'ai l'intention de tout ce que j'ai appris et le transformer en un simple crash de l'outil de mieux que le de lotan outil (probablement de lotan v2).

J'ai mis à jour de lotan à l'appui de la fourniture de l' load address manuellement: https://github.com/NSProgrammer/natos

Je pense que ce post peut vous aider, https://stackoverflow.com/a/12559150/1773317.
Joe s'engager à semelles de mon problème.

La raison en est que mon .app et .dSYM fichiers ne peuvent pas être indexés par spotlight, donc mon XCode ne peut pas symbolicate le crash de l'info correctement.

Mon cas:
Je reçois le crash chaînes de la NSException.callStackSymbols.

Le crash trace de la pile semble de cette façon:

2   AppName                               0x00000001006c75b4 AppName + 2356660\r3   AppName                               0x00000001004f5cfc AppName + 449788\r4   UIKit                               0x000000018c0a8968 \u003credacted\u003e + 108\r5   UIKit      0x000000018c0a9328 \u003credacted\u003e + 28\r6   UIKit                               0x000000018beea250 \u003credacted\u003e + 1320\r7   UIKit                               0x000000018beede98 \u003credacted\u003e + 188\r8   UIKit                               0x000000018bcb5820 \u003credacted\u003e + 116\r9   UIKit                               0x000000018bbdec88 \u003credacted\u003e + 760\r10  UIKit                               0x000000018bbde610 \u003credacted\u003e + 312\r11  UIKit                               0x000000018bbde31c \u003credacted\u003e + 296\r12  UIKit                               0x000000018bbde3bc \u003credacted\u003e + 456\r13  QuartzCore                          0x0000000185b93b7c \u003credacted\u003e + 284\r14  libdispatch.dylib                   0x00000001811a8a2c \u003credacted\u003e + 16\r15  libdispatch.dylib                   0x00000001811b5654 \u003credacted\u003e + 1012\r16  CoreFoundation                      0x0000000181851650 \u003credacted\u003e + 12\r17  CoreFoundation                      0x000000018184f1a8 \u003credacted\u003e + 2272\r18  CoreFoundation                      0x000000018176f488 CFRunLoopRunSpecific + 552\r19  GraphicsServices                    0x0000000183735020 GSEventRunModal + 100\r20  UIKit         0x000000018bc09cc0 UIApplicationMain + 236\r21  AppName                               0x000000010048f714 AppName + 30484\r22  libdyld.dylib 0x000000018120dfc0 \u003credacted\u003e + 4

Ne comprennent pas bitcode, comme Apple peut recompiler votre code, et dsym des fichiers à partir d'archives de l'Organisateur ne correspond pas.

Exécutez ce script bash:

#!/bin/bash
appName=AppName
runtimeAddress=0x00000001006c75b4
relativeAddress=2356660
loadAddress=`echo "obase=16;ibase=10;$((runtimeAddress-relativeAddress))" | bc`
atos -o $appName.app/$appName -l $loadAddress $runtimeAddress -arch arm64

En supposant que vous avez créé un test.sh (touch test.sh). Si il n'est pas possible d'exécuter le sctipt (./test.sh) en raison d'un problème d'autorisations: l'appel de la commande chmod +x test.sh Maintenant ./test.sh devrait fonctionner. Et générer le résultat.

Ainsi il est possible de symbolicate l'écrasement de fichiers à l'aide de AppName.app.dSYM fichier:

#!/bin/bash
appName=AppName
runtimeAddress=0x00000001006c75b4
relativeAddress=2356660
loadAddress=`echo "obase=16;ibase=10;$((runtimeAddress-relativeAddress))" | bc`
atos -o $appName.app.dSYM/Contents/Resources/DWARF/$appName -l $loadAddress $runtimeAddress -arch arm64