title: iOS crash report symbolication without dsym - symbol address outside the addresses seen in the binary
body: <p>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. </p>
  
  <p>To start with,  here is the stack trace of the crashed thread: </p>
  
  <pre><code>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
  ...
  </code></pre>
  
  <p>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 </p>
  
  <pre><code>atos -arch arm64 -o myapp -l 0x100080000 0x0000000100ec4738
  </code></pre>
  
  <p>and I get the output from the above command as </p>
  
  <pre><code>0x0000000100e44738 (in myapp) + 544
  </code></pre>
  
  <p>This is partially expected because I do not have the dsym file.  </p>
  
  <p>Please note that <code>0x0000000100e44738</code> can also be obtained if we calculate </p>
  
  <p><code>symbol address as = (slide + stack - load address)</code></p>
  
  <p>slide is <code>0x0000000100000000</code>   ( found as vmaddr  from  <code>otool -arch arm64 -l myapp | grep -B 3 -A 8 -m 2 "__TEXT"</code> )</p>
  
  <p>so  <code>0x0000000100000000 + 0x0000000100ec4738 - 0x100080000 = 0x100e44738</code>  same as above address that atos returned. </p>
  
  <p>Now the problem is, I do not find <code>0x100e44738</code> symbol address in the addresses from the TEXT section in the binary that I obtain using below otool command </p>
  
  <pre><code>otool -tvV myapp
  </code></pre>
  
  <p>The start of the above command looks like this. </p>
  
  <pre><code>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]
  ...
  </code></pre>
  
  <p>We can clearly see the starting address from the <code>otool -tvV (0x101262f40)</code> is greater than the <code>symbol address (0x100e44738)</code>.  So I'm unable to find what I missed or how to go about from here.  </p>
  
  <p>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. </p>
  
  <p>Any help or pointers is most appreciated. </p>