3

I'm using BugSense to track crashes from an iOS App. Recently I noticed problems symbolicating stack traces from live usage.

The problem is that Apple introduced address space randomization with iOS 4.3 so that the stack address of interest cannot solely be used to retrieve the correct methods that caused the crash.

Currently I'm trying to get the correct address by calculating

symbol address = slide + stack address - load address

I already have slide and stack address but from my understanding the load address can only be found in the crash report which I cannot get via BugSense. The stack trace looks like

0 CoreFoundation 0x342723e7 + 162
1 libobjc.A.dylib 0x3bf63963 objc_exception_throw + 30
2 CoreFoundation 0x3427229d + 0
3 Foundation 0x34b48fa3 + 90
4 UIKit 0x360b5bd9 + 7640
5 MyApp 0x000c6e99 0xb3000 + 81561
6 UIKit 0x3623c2ff 0x3607e000 + 1827583
7 UIKit 0x361b8737 0x3607e000 + 1287991
8 UIKit 0x361a9869 0x3607e000 + 1226857
9 UIKit 0x361a97ad 0x3607e000 + 1226669
10 CoreFoundation 0x34247941 0x341b0000 + 620865
11 CoreFoundation 0x34245c39 0x341b0000 + 613433
12 CoreFoundation 0x34245f1d 0x341b0000 + 614173
13 CoreFoundation 0x341b923d CFRunLoopRunSpecific + 356
14 CoreFoundation 0x341b90c9 CFRunLoopRunInMode + 104
15 GraphicsServices 0x37d9733b GSEventRunModal + 74
16 UIKit 0x360d52b9 UIApplicationMain + 1120
17 MyApp 0x000b61bf 0xb3000 + 12735
18 MyApp 0x000b4a08 0xb3000 + 6664

Is there another way to symbolicate this address or to get the respective load address?

sven.b
  • 65
  • 1
  • 6
  • possible duplicate of [Symbolicating iPhone App Crash Reports](http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports) – Ben S Mar 07 '13 at 10:06
  • @Benoit I think the problem is, that sven.b has not enough reputation to comment on the answer you just postet. And sven.b argues that the given answer in that thread is not valid anymore, beause of the space randomization that was added to iOS 4.3. – Pascal Klein Mar 07 '13 at 10:11
  • Thank you Benoit, the post you mentioned is kind of outdated. The atos command is correct but the symbol address cannot be taken from the stack trace any more as described above. – sven.b Mar 07 '13 at 10:11
  • That argument is not correct. Crash logs have the ASLR offset used for the application binary as well as the offset for all linked libraries. `atos` is capable of symbolicating crash logs > 4.3 without issues. – Ben S Mar 07 '13 at 10:12
  • That is correct. But I do only have access to a stack trace and no crash log. That's the problem. – sven.b Mar 07 '13 at 10:15
  • 1
    You should ask Bugsense to provide you the complete standard format crash report, so you get all data needed. The `load address` is shown in the binary images section. If they can't, you might want to consider another service that does things better. Side note: the proposed duplicates accepted answer is indeed wrong, see my comment: http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports#comment21083015_4954949 – Kerni Mar 07 '13 at 10:42
  • One addition: Could you post the data of the crash report that you have. Depending on what is shown, it might also be possible to derive the information. – Kerni Mar 07 '13 at 11:24

1 Answers1

1

The load address is 0xb3000.

Luckily you have the symbols stripped from your app binary, otherwise this wouldn't be visible.

Also this crash happened because of an exception being thrown, so the crash report should give you a Last Exception Backtrace showing where the actual exception happened and the actual exception reason. It is likely that the call in line 5 of the posted stack trace doesn't give you a lot of information on that. The crash information you are getting looks pretty limited :(

Kerni
  • 15,241
  • 5
  • 36
  • 57