iOS崩溃日志堆栈跟踪的C#部分没有任何意义 [英] C# part of iOS crash log stack trace doesn't make any sense
问题描述
我有一个崩溃日志文件，我使用二进制文件中的信息进行符号化 . 我已验证崩溃日志与此特定二进制文件有关.我什至能够获得C#级堆栈跟踪:
I have a crash log file that I symbolicate using information in the binary file. I verified that crash log is related to this particular binary. I'm even able to get out C#-level stack trace:
$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
但是，我以这种方式获得的堆栈跟踪没有任何意义！这些方法不会互相调用，也没有关联.可能缺少一些中间堆栈跟踪框架吗?这样在我的代码上下文中可能有意义.
However, the stack trace I get that way doesn't make any sense! These methods don't call each other, and aren't related. May be there are some intermediate stack trace frames missing? It could make sense in context of my code that way.
更新
我注意到我有两个崩溃日志，这是一件非常奇怪的事情.测试人员针对两种测试描述了相同的场景.其中之一看起来像这样:
I've noticed a very strange thing with two crash logs that I've got. The tester described the same scenario for both tests. One of them looks like this:
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
系统库的地址相同，但应用程序本身的地址不同.但是，在"dev"行上，您可能会注意到地址偏移是相同的；但是，其中一个具有0x7c000作为文件地址，而另一个具有0xb4000.当我从相同编号的行中给出atos地址时，结果是不同的，而且我不知道哪一个是正确的(如果有的话).
The addresses are the same for the system libraries, but different for the app itself. However, on "dev" lines, you may notice that the address shift is the same; however, one of them has 0x7c000 as file address, and the other has 0xb4000. When I give the atos addresses from the lines of the same number, the result is different, and I don't know which one is correct, if any is.
寄存器也非常相似:
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
在第二个中，这也暗示了相似性.
in the second, which also suggests a similarity.
Update2
有人告诉我，当我在atos的第一个地址列(不同的地址)中使用地址时，我可能犯了一个错误.这些地址应该在系统内存空间中.另一方面，末尾的地址移位(相同)应该位于文件空间中.但是，当我将它们转换为十六进制并在atos中使用它们时，我得到的功能和方法仍然毫无意义.
I was told that I probably made a mistake when I used the addresses in the first address column (those that are different) for atos. These addresses are supposed to be in the system memory space; the address shifts at the end (which are the same) on the other hand, are supposed to be in the file space. However, when I convert them to hex and use them in atos, the functions and methods that I get still make no sense.
推荐答案
我的最新更新是正确的答案.原来，我确实需要使用地址移位，而且 = brel = brel = b> = brel = brel = brel = brel = brel = brel = brel = brel = b> = brel = brel = brel = brel = brel = brel = brel = blow = rel>> brel = brel = b> rel = rel> =" bvm = brel = b> rel ="rel">"bvm = b"> = rel> rel ="b"> = bvm = brel = rel;"我曾经使该过程有点自动化，也许您会发现它有用:
My last update was the correct way to the answer. Turns out, I did need to use the address shift, but also moved by slide. Here's a fish function I used to automate the process a bit, may be you'll find it useful:
function symb
echo "obase=16; " (math $argv+16384)|bc|atos -arch armv7 -o "dev.app/dev"
end
(16384是我的可执行文件的幻灯片的十进制形式)
(16384 is a decimal form of a slide for my executable)
这篇关于iOS崩溃日志堆栈跟踪的C#部分没有任何意义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
