2

In a production app with the debug information stripped out, how do you convert the output of:

NSLog(@"Stack Trace: %@", [exception callStackSymbols]);

To an legible class and method name? A line number would be a blessing.

Here's the output I'm getting:

0   CoreFoundation                      0x23d82f23 <redacted> + 154
1   libobjc.A.dylib                     0x23519ce7 objc_exception_throw + 38
2   CoreFoundation                      0x23cb92f1 <redacted> + 176
3   MyApp                              0x23234815 MyApp + 440341

The final line is the bread and butter line, but when I use dwarf to find the address, nothing exists.

dwarfdump --arch armv7 MyApp.dSYM --lookup 0x00234815 | grep 'Line table'

I've read here that you need to convert the stack address to something else for dwarf or atos:

https://stackoverflow.com/a/12464678/2317728

How would I find the load address or slide address to perform the calculation? Is there not a way to calculate all this prior to sending the stacktrace to the log from within the app? If not, how would I determine and calculate these values after receiving the stack trace? Better yet, is there an easier solution I'm missing?

Note I cannot just wait for crash reports since the app is small and they will never come. I'm planning on sending the stack traces to our server to be fixed as soon as they appear.

EDITORIAL

The crash reporting tools in iOS are very rough, particularly when compared to Android. In android, the buggy lines are sent to Google analytics, you use the map to debug the line--simple (comparatively). For iOS, you are confronted with: a) waiting on user bug reports (not reasonable for a small app), b) sending stack traces to a server where there are scant tools or information on how to symbolicate the stack traces, c) relying on large quasi-commercial 3rd party libraries. This definitely makes it harder to build and scale up--hoping Apple will eventually take notice. Even more hopeful someone has spotted an easier solution I might have missed ;)

Thanks for your help!

Community
  • 1
  • 1
Phyllis Sutherland
  • 307
  • 4
  • 14
  • 2
    Have you looked at https://www.plcrashreporter.org/ which powers many of those commercial crash reporting services? It sounds like you might be about to try to reinvent much of that tool. – Jonah Jun 25 '14 at 14:23
  • Thanks for the suggestion--they seem like a good offering, but the size of that project is several times the size of my app. If I could just figure out how to transpose the output into something intelligible, the server stuff would just take 30 min and I could avoid adding a large 3rd party codebase to the project. – Phyllis Sutherland Jun 25 '14 at 14:33
  • 1
    Some notes: 1. you will only get reports with exceptions via this mechanism, no crashes caused by signal handler. 2. To symbolicate the data of `callStackSymbols` you need to write your own parser and logic and using `atos` with the correct parameters. 3. The size of PLCrashReporter is exactly what? The code, the static library binary? Both don't give a hint on how much bigger your app will be unless you link it and check. 4. Sending crash reports when the exception happens is a bad bad idea. 5. Crashes/Exceptions are way different than what you know from Android. Don't use the same approach! – Kerni Jun 25 '14 at 14:57

1 Answers1

0

A suggestion, you can easily get the method name, exception reason and line number using:

NSLog(@"%@ Exception in %s on %d due to %@",[exception name],__PRETTY_FUNCTION__,__LINE__,[exception reason]);
Midhun MP
  • 103,496
  • 31
  • 153
  • 200
  • Thanks I added in the .name and .reason. The rest unfortunately points to the line in my exception handler. I also don't think it would work with the symbols stripped in a production app. – Phyllis Sutherland Jun 25 '14 at 14:29