Alexey Andronov
Alexey Andronov

Reputation: 602

How to symbolize stack traces of a stripped shared library

I have a crash report for my app from Google Play services which looks like this:

backtrace:
  #00  pc 00000000001b46a0  library.so
  #01  pc 0000000000604464  library.so
  #02  pc 0000000000c8ed1c  library.so

I also have a .map file for library.so which helps me to locate function names and transform stacktrace into more readable format:

backtrace:
  #00  pc 00000000001b46a0  library.so  foo()
  #01  pc 0000000000604464  library.so  bar()
  #02  pc 0000000000c8ed1c  library.so  zoo()

But manually resolving function names is error-prone and it doesn't give me the line numbers is source code which caused the crash.

I've considered an idea to store an unstripped version of library.so when publishing new version so that I could use ndk-stack tool, but AFAIK function addresses for stripped and unstripped binaries are differ.

So my question is it possible to continue publishing stripped binary and have means to automatically symbolize stack traces with line numbers?

Any suggestions will be greatly appreciated

Upvotes: 1

Views: 943

Answers (1)

Alex Cohn
Alex Cohn

Reputation: 57203

ndk-stack is exactly built for this purpose, don't worry. You feed the unstripped library.so to it, and get the best stack trace you can achieve!

Make sure that you don't mix debug/releas versions, and keep the unstripped version for every binary that goes into production (or make sure that you can reliably rebuild such unstripped version for the corresponding git tag).

Upvotes: 6

Related Questions