Search code examples
c++ioscrash-reportssegmentation-fault

iOS crash report symbolication without dsym - symbol address outside the addresses seen in the binary


I'm trying to symbolicate an iOS crash report for which I do not have the dsym file. I know I will not be able to get a nice file_name : line number symbolication but finding out where in the assembly section of the code the crash is will be good enough.

To start with, here is the stack trace of the crashed thread:

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
...

I have a decrypted binary and verified the uuid's from crash report and the binary matches. To manually symbolicate a stack address, I do this

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

and I get the output from the above command as

0x0000000100e44738 (in myapp) + 544

This is partially expected because I do not have the dsym file.

Please note that 0x0000000100e44738 can also be obtained if we calculate

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

slide is 0x0000000100000000 ( found as vmaddr from otool -arch arm64 -l myapp | grep -B 3 -A 8 -m 2 "__TEXT" )

so 0x0000000100000000 + 0x0000000100ec4738 - 0x100080000 = 0x100e44738 same as above address that atos returned.

Now the problem is, I do not find 0x100e44738 symbol address in the addresses from the TEXT section in the binary that I obtain using below otool command

otool -tvV myapp

The start of the above command looks like this.

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]
...

We can clearly see the starting address from the otool -tvV (0x101262f40) is greater than the symbol address (0x100e44738). So I'm unable to find what I missed or how to go about from here.

This stack trace is for a SIGSEGV exception and I'm not sure if that changes anything. I have tried the exact same steps of manual symbolication in one another sample app with SIGABRT exception and I do see it was able to point out the crash to exact line in the assembly.

Any help or pointers is most appreciated.


Solution

  • I looks like a problem with a NSURLConnection. Usually that means that there is a delegate that is not being unset correctly on dealloc (NSURLConnection is assign - not weak so you have to set it to nil manually). Look for places in your code that use NSURLConnection or other networking like code. Be especially mindful of views or viewController that set themselves as the delegate of network request because views often leave memory when the user leave the page.