Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Support Play formatted traces #1898

Closed
garanj opened this issue Jun 26, 2023 · 7 comments
Closed

[FR] Support Play formatted traces #1898

garanj opened this issue Jun 26, 2023 · 7 comments

Comments

@garanj
Copy link

garanj commented Jun 26, 2023

Description

Support traces from Play Console:

in traces from play console addresses look like 0x000000000006263c
ndk-stack expects addresses like 000000000006263c without leading 0x

It would be great if ndk-stack supported this without the need for additional pre-processing.

@DanAlbert
Copy link
Member

Can you provide some examples? I have no idea what a play trace looks like. Why is Play mangling the stack trace?

@samkevich
Copy link

Here is an example of the stack trace:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 8226 >>> com.whatsapp <<<

backtrace:
  #00  pc 0x000000000006263c  /apex/com.android.runtime/lib/bionic/libc.so (abort+172)
  #01  pc 0x00000000006a5b3b  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #02  pc 0x0000000000733d43  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #03  pc 0x00000000006d59e7  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #04  pc 0x00000000006cfbe9  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #05  pc 0x00000000006cddf3  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #06  pc 0x00000000006e1d63  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #07  pc 0x00000000005aa5bf  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #08  pc 0x00000000005aa3d1  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #09  pc 0x00000000005b343f  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #10  pc 0x000000000015732b  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #11  pc 0x00000000001560eb  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #12  pc 0x0000000000157c15  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #13  pc 0x000000000022a3c9  /data/app/~~isAudeGZUqsyCrf2P96YvA==/com.whatsapp-jQCbsph_Q4u3Tk7m3XMHNQ==/base.apk
  #14  pc 0x00000000000ab4fb  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+40)
  #15  pc 0x0000000000063b77  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30)
@samkevich
Copy link

samkevich commented Jul 4, 2023

I believe a fix should change this regex to something like r".* +(#[0-9]+) +pc ([0-9a-fx-x]+) +(([^ ]+).*)"
It seems llvm-symbolizer accepts both address formats: 0x000000000006263c and 000000000006263c, so the problem is only in parsing the address

@DanAlbert
Copy link
Member

@cferris1000, it looks to me like it's not actually anything to do with Play, the trace format just changed at some point? Is that right?

@DanAlbert
Copy link
Member

@cferris1000 confirmed that the trace format hasn't changed, so it's coming to you mangled from play.

Digging in to fix that though, I think ndk-stack is actually the one doing the mangling, and Play was just kind enough to run ndk-stack (or maybe just addr2line?) for you. But I assume you're running it a second time because you've got more symbol info than Play had? You're probably interested in https://support.google.com/googleplay/android-developer/answer/9848633?#zippy=%2Cnative-generate-a-debug-symbols-file then, and then you won't need ndk-stack at all.

That said, I don't think this is hard to fix to allow reprocessing stuff that already went through ndk-stack, so will do that too.

@DanAlbert
Copy link
Member

Actually that's not what that is. The original crash trace begins with *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***, but ndk-stack's output begins with ********** Crash dump: **********. llvm-addr2line doesn't rewrite that either... I've got no clue what's causing that. Easy fix either way, I just wish I knew why...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants