Question
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:
https://stackoverflow.com/questions/19539907
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian$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.
Solution
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)
