Symbolique de rapport de plantage iOS sans adresse de symbole dsym en dehors des adresses vues dans le binaire

Question

J'essaye de symboliser un rapport de plantage iOS pour lequel je n'ai pas le fichier dsym. Je sais que je ne serai pas en mesure d'obtenir une belle symbolisation du nom de fichier, mais trouver dans la section d'assemblage du code le crash sera suffisant.

Pour commencer, voici la trace de la pile du fil écrasé:

Thread 3 name: Dispatch queue: com.unity3d.WebOperationQueue :: NSOperation 0x1483250e0 (QOS: USER_INTERACTIVE) 
Thread 3 Crashed: 
0 myapp      0x0000000100ec4738 0x100080000 + 14960440 
1 myapp      0x000000010120e0fc 0x100080000 + 18407676 
2 myapp      0x00000001011d7e00 0x100080000 + 18185728 
3 myapp      0x0000000100085cfc 0x100080000 + 23804 
4 CFNetwork     0x0000000185027780 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 80 
... 

J'ai un binaire déchiffré et vérifié les années UUID du rapport de l'accident et les matches binaires. Pour symbolicate manuellement une adresse de pile, je fais

atos -arch arm64 -o myapp -l 0x100080000 0x0000000100ec4738 

et je reçois la sortie de la commande ci-dessus

0x0000000100e44738 (in myapp) + 544 

Ceci est partiellement prévu parce que je n'ai pas le fichier dsym.

S'il vous plaît noter que 0x0000000100e44738 peut également être obtenu si l'on calcule

symbol address as = (slide + stack - load address)

slide est 0x0000000100000000 (trouvé comme vmaddr de otool -arch arm64 -l myapp | grep -B 3 -A 8 -m 2 "__TEXT")

si 0x0000000100000000 + 0x0000000100ec4738 - 0x100080000 = 0x100e44738 comme ci-dessus adresse qu'Atos retour.

Maintenant, le problème est, je ne trouve pas 0x100e44738 adresse de symbole dans les adresses de la section de texte dans le binaire que j'obtenir à l'aide ci-dessous otool commande

otool -tvV myapp 

Le début de la commande ci-dessus ressemble à ceci.

myapp: 
(__TEXT,__text) section 
__ZNK5physx14NpSceneQueries10multiQueryINS_12PxRaycastHitEEEbRKNS_15MultiQueryInputERNS_13PxHitCallbackIT_EENS_7PxFlagsINS_9PxHitFlag4EnumEtEEPKNS_12PxQueryCacheERKNS_17PxQueryFilterDataEPNS_21PxQueryFilterCallbackEPNS_20BatchQueryFilterDataE: 
0000000101262f40 stp x28, x27, [sp, #-96]! 
0000000101262f44 stp x26, x25, [sp, #16] 
0000000101262f48 stp x24, x23, [sp, #32] 
0000000101262f4c stp x22, x21, [sp, #48] 
0000000101262f50 stp x20, x19, [sp, #64] 
0000000101262f54 stp x29, x30, [sp, #80] 
... 

On voit bien l'adresse de départ du otool -tvV (0x101262f40) est supérieure à la symbol address (0x100e44738). Donc, je suis incapable de trouver ce que j'ai manqué ou comment aller d'ici.

Cette trace de pile est pour une exception SIGSEGV et je ne suis pas sûr si cela change quelque chose. J'ai essayé exactement les mêmes étapes de la symbolisation manuelle dans un autre exemple d'application avec l'exception SIGABRT et je vois qu'il était capable de signaler le crash à la ligne exacte dans l'assemblage.

Toute aide ou pointeur est très appréciée.

Answer 1

Je ressemble à un problème avec un NSURLConnection. Habituellement, cela signifie qu'il y a un délégué qui n'est pas mis à zéro correctement sur dealloc (NSURLConnection est assigné - pas faible donc vous devez le mettre à zéro manuellement). Recherchez les endroits dans votre code qui utilisent NSURLConnection ou un autre code réseau. Soyez particulièrement attentif aux vues ou à viewController qui se définissent comme délégué de la requête réseau car les vues quittent souvent la mémoire lorsque l'utilisateur quitte la page.