1

I have an internal crash reporter which used to work great before bitcode, but now I'm getting this information:

0 MYAPP 0x00000001000f7fcc MYAPP + 245708
1 MYAPP 0x00000001000e734c MYAPP + 176972
2 CoreFoundation 0x0000000184671c88 + 652
3 libobjc.A.dylib 0x0000000183ce023c + 112
4 libc++abi.dylib 0x0000000183cd2f44 + 16
5 libc++abi.dylib 0x0000000183cd2b10 __cxa_rethrow + 144
6 libobjc.A.dylib 0x0000000183ce0120 objc_exception_rethrow + 44
7 CoreFoundation 0x0000000184555728 CFRunLoopRunSpecific + 552
8 GraphicsServices 0x0000000185a64088 GSEventRunModal + 180
9 UIKit 0x00000001893ccd90 UIApplicationMain + 204
10 MYAPP 0x000000010011c6a4 MYAPP + 394916
11 libdyld.dylib 0x00000001840f68b8 + 4

I've seen several SO questions where they all mention they see their lines as this:

5   MyApp                   0x0044e89a 0x29000 + 4348058

With 2 hex values, but for some reason I'm only getting 1 and when I run this command:

atos -arch arm64 -o MYAPP 0x00000001000f7fcc

I get this answer:

0x00000001000f7fcc (in MYAPP)

Which doesn't help me at all of course. What am I doing wrong?

EDIT:

My question was marked as a posible duplicate of this other question, but as I mentioned in my comment below, that user's log already has some method names in there. So it's not the same scenario. The accepted answer there mentions stack address and load address, the 2 hex values I was referring to before which I don't seem to have.

Jan
  • 2,462
  • 3
  • 31
  • 56
  • Possible duplicate of [iOS crash reports: atos not working as expected](https://stackoverflow.com/questions/13574933/ios-crash-reports-atos-not-working-as-expected) – Kerni May 25 '17 at 15:40
  • Hi @Kerni that's one of the OS questions I was referring to. But that user's log already has some method names in there. So it's not the same. The accepted answer there mentions `stack address` and `load address`, the 2 hex values I was referring to in my question which I don't seem to have – Jan May 25 '17 at 15:45
  • You are calling `atos` only with the memory address of the frame at runtime. The symbol file doesn't know in which memory address the app is loaded into, so it doesn't know where the relative start is. That information is provided by the load address in the binary images section of the crash report. If you don't have that information, you will not be able to get the symbols. – Kerni May 25 '17 at 15:54
  • Hi @Kerni the piece of text that I copied here is all the information that I have. It's basically the result of calling `[NSThread callStackSymbols]`. How can I get the load address in order to include it inside the crash report? Thank you! – Jan May 25 '17 at 15:59
  • This call will not provide you with anything helpful. You need a full crash report, either the one iOS generates or by using a 3rd party SDK/service. – Kerni May 25 '17 at 16:19
  • Mmm, that's a problem... It's an enterprise app, so no App Store involved, and our client forbids us from using 3rd party services... I'm sure there is a way to get this information somehow if 3rd party services can access it. Do you happen to know any open source library we might have a look at so we can get the full info we need? Thank you very much @Kerni – Jan May 25 '17 at 16:25

0 Answers0