iOS崩溃日志堆栈跟踪的C＃部分没有任何意义
我有一个崩溃日志文件，我用二进制文件中的信息符号化 。 我validation了崩溃日志与这个特定的二进制文件有关 。 我甚至能够脱离C＃级堆栈跟踪：
$atos -arch armv7 -o 'dev.app'/'dev' 0x00156ac0 m_Action_Spin_MakeChips_Cell_double_double_ulong_System_Collections_Hashtable_System_Collections_Generic_List_1_Chip (in dev) + 1316 但是，我得到的堆栈跟踪没有任何意义！ 这些方法不会互相呼叫，也不相关。 可能是有一些中间的堆栈跟踪帧丢失？ 这种方式在我的代码中可能是有意义的。
更新
我已经注意到一个非常奇怪的事情，我有两个崩溃日志。 testing人员对两种testing都描述了相同的情况。 其中一个看起来像这样：
0 dev 0x00cbff6c 0x7c000 + 12861292 1 dev 0x00bd4810 0x7c000 + 11896848 2 dev 0x01379838 0x7c000 + 19912760 3 dev 0x0141ba70 0x7c000 + 20576880 4 dev 0x0141bbf4 0x7c000 + 20577268 5 dev 0x0141fe68 0x7c000 + 20594280 6 dev 0x01421d7c 0x7c000 + 20602236 7 dev 0x013899cc 0x7c000 + 19978700 8 dev 0x0138a264 0x7c000 + 19980900 9 dev 0x013a59e0 0x7c000 + 20093408 10 dev 0x01379fa4 0x7c000 + 19914660 11 libsystem_c.dylib 0x3aa5be90 0x3aa23000 + 233104 12 libsystem_c.dylib 0x3aa272dc 0x3aa23000 + 17116 13 dev 0x002ea644 0x7c000 + 2549316 14 dev 0x002ea3ec 0x7c000 + 2548716 15 dev 0x002e8688 0x7c000 + 2541192 16 dev 0x002e8688 0x7c000 + 2541192 17 dev 0x00156ac0 0x7c000 + 895680 18 dev 0x002e8688 0x7c000 + 2541192 19 dev 0x0026a248 0x7c000 + 2024008 20 dev 0x002fa25c 0x7c000 + 2613852 21 dev 0x002f8f54 0x7c000 + 2608980 22 dev 0x0114bbac 0x7c000 + 17628076 23 dev 0x0114b7c4 0x7c000 + 17627076 24 dev 0x0114b780 0x7c000 + 17627008 25 dev 0x01140b38 0x7c000 + 17582904 26 dev 0x01140b64 0x7c000 + 17582948 27 dev 0x010977ec 0x7c000 + 16889836 28 dev 0x01097794 0x7c000 + 16889748 29 dev 0x0111d578 0x7c000 + 17438072 30 dev 0x00f37954 0x7c000 + 15448404 31 dev 0x00cc2e94 0x7c000 + 12873364 32 QuartzCore 0x3454c094 0x34511000 + 241812 33 QuartzCore 0x3454bfec 0x34511000 + 241644 34 IOMobileFramebuffer 0x367a3fd4 0x3679f000 + 20436 35 IOKit 0x33546446 0x33543000 + 13382 36 CoreFoundation 0x329295d8 0x3289d000 + 574936 37 CoreFoundation 0x32934170 0x3289d000 + 618864 38 CoreFoundation 0x32934112 0x3289d000 + 618770 39 CoreFoundation 0x32932f94 0x3289d000 + 614292 40 CoreFoundation 0x328a5eb8 0x3289d000 + 36536 41 CoreFoundation 0x328a5d44 0x3289d000 + 36164 42 GraphicsServices 0x364582e6 0x36453000 + 21222 43 UIKit 0x347bb2fc 0x34764000 + 357116 44 dev 0x00082048 0x7c000 + 24648 45 dev 0x00081f94 0x7c000 + 24468
另一个像这样：
0 dev 0x00cf7f6c 0xb4000 + 12861292 1 dev 0x00c0c810 0xb4000 + 11896848 2 dev 0x013b1838 0xb4000 + 19912760 3 dev 0x01453a70 0xb4000 + 20576880 4 dev 0x01453bf4 0xb4000 + 20577268 5 dev 0x01457e68 0xb4000 + 20594280 6 dev 0x01459d7c 0xb4000 + 20602236 7 dev 0x013c19cc 0xb4000 + 19978700 8 dev 0x013c2264 0xb4000 + 19980900 9 dev 0x013dd9e0 0xb4000 + 20093408 10 dev 0x013b1fa4 0xb4000 + 19914660 11 libsystem_c.dylib 0x3aa5be90 0x3aa23000 + 233104 12 libsystem_c.dylib 0x3aa272dc 0x3aa23000 + 17116 13 dev 0x00322644 0xb4000 + 2549316 14 dev 0x003223ec 0xb4000 + 2548716 15 dev 0x00320688 0xb4000 + 2541192 16 dev 0x00320688 0xb4000 + 2541192 17 dev 0x0018eac0 0xb4000 + 895680 18 dev 0x00320688 0xb4000 + 2541192 19 dev 0x002a2248 0xb4000 + 2024008 20 dev 0x0033225c 0xb4000 + 2613852 21 dev 0x00330f54 0xb4000 + 2608980 22 dev 0x01183bac 0xb4000 + 17628076 23 dev 0x011837c4 0xb4000 + 17627076 24 dev 0x01183780 0xb4000 + 17627008 25 dev 0x01178b38 0xb4000 + 17582904 26 dev 0x01178b64 0xb4000 + 17582948 27 dev 0x010cf7ec 0xb4000 + 16889836 28 dev 0x010cf794 0xb4000 + 16889748 29 dev 0x01155578 0xb4000 + 17438072 30 dev 0x00f6f954 0xb4000 + 15448404 31 dev 0x00cfae94 0xb4000 + 12873364 32 QuartzCore 0x3454c094 0x34511000 + 241812 33 QuartzCore 0x3454bfec 0x34511000 + 241644 34 IOMobileFramebuffer 0x367a3fd4 0x3679f000 + 20436 35 IOKit 0x33546446 0x33543000 + 13382 36 CoreFoundation 0x329295d8 0x3289d000 + 574936 37 CoreFoundation 0x32934170 0x3289d000 + 618864 38 CoreFoundation 0x32934112 0x3289d000 + 618770 39 CoreFoundation 0x32932f94 0x3289d000 + 614292 40 CoreFoundation 0x328a5eb8 0x3289d000 + 36536 41 CoreFoundation 0x328a5d44 0x3289d000 + 36164 42 GraphicsServices 0x364582e6 0x36453000 + 21222 43 UIKit 0x347bb2fc 0x34764000 + 357116 44 dev 0x000ba048 0xb4000 + 24648 45 dev 0x000b9f94 0xb4000 + 24468
系统库的地址是相同的，但是应用程序本身不同。 但是，在“开发”线上，您可能会注意到地址转换是相同的; 但是，其中一个具有0x7c000作为文件地址，另一个具有0xb4000。 当我从同一个号码的号码给atos地址的时候，结果是不同的，我不知道哪一个是正确的，如果有的话。
寄存器也看起来非常相似：
Thread 0 crashed with ARM Thread State (32-bit): r0: 0x00000001 r1: 0x3c58cb88 r2: 0x0ae7ce50 r3: 0x017a3bc0 r4: 0x2fd86088 r5: 0x21692590 r6: 0x00000002 r7: 0x2fd85f70 r8: 0x00000001 r9: 0x02270000 r10: 0x1ea63808 r11: 0x2fd85f78 ip: 0x016ed6a4 sp: 0x2fd85f70 lr: 0x011be598 pc: 0x00cbff6c cpsr: 0x60000010
在第一和
Thread 0 crashed with ARM Thread State (32-bit): r0: 0x00000001 r1: 0x3c58cb88 r2: 0x0b8010c0 r3: 0x017dbbc0 r4: 0x2fd4e088 r5: 0x205cc820 r6: 0x00000002 r7: 0x2fd4df70 r8: 0x00000001 r9: 0x0a158900 r10: 0x1d26da08 r11: 0x2fd4df78 ip: 0x017256a4 sp: 0x2fd4df70 lr: 0x011f6598 pc: 0x00cf7f6c cpsr: 0x60000010
在第二，这也表明了相似之处。
UPDATE2
有人告诉我，当我在atos的第一个地址栏中使用不同的地址时，我可能犯了一个错误。 这些地址应该在系统内存空间中; 另一方面，地址转换结束（相同），应该是在文件空间。 但是，当我将它们转换为hex并在atos中使用它时，我所得到的function和方法仍然没有意义。
我最后的更新是正确的答案。 事实certificate，我确实需要使用地址转移，但也通过幻灯片移动 。 这里有一个鱼函数，我用它来自动化一下，可能你会发现它很有用：
function symb echo "obase=16; " (math $argv+16384)|bc|atos -arch armv7 -o "dev.app/dev" end
（16384是我的可执行文件的幻灯片的小数forms）