C# part of iOS crash log stack trace doesn't make any sense

南笙酒味 提交于 2019-12-11 04:53:18

问题


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.

Update

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

And the other like this:

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

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.

The registers also look very similar:

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

in the first and

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

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.


回答1:


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 is a decimal form of a slide for my executable)



来源:https://stackoverflow.com/questions/19539907/c-sharp-part-of-ios-crash-log-stack-trace-doesnt-make-any-sense

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!