On Wed, Apr 17, 2024 at 3:13 PM '
jim.b...@couchbase.com' via
android-ndk <
andro...@googlegroups.com> wrote:
>
> Hello again, and apologies for a question that probably has more to do with C and C++ itself than Android specifically but this problem has been plaguing me for quite some time. Whenever we get a report from the field including a tombstone, the stack traces are underwhelming. It seems there is not enough information present in the production native libraries to generate a stack trace. I guess C++ just wants to make this difficult or something but I notice that other system libraries appear to have it right. Here is a really bad example from a latest bug report. This is via .NET, for informational purposes.
thanks for mentioning that, because i suspect that's the active ingredient here!
> backtrace:
> #00 pc 00000000001ae3a4 /data/app/~~Y9JE4-VEbGMpV5xJIXd8Ag==/embc.zack-JXDgGUeOK9XH-CUJJYT4ow==/lib/arm64/libLiteCore.so (BuildId: 5a2f59a0c2d7ac3056f8b8f783b3ace25b38b0e8)
> #01 pc 000000000004fbd0 <anonymous:6db0603000>
>
> Not only are function names not present in the final frame, but there are only two frames total and one of them is "anonymous". Sometimes I get an actual trace, without function information for C++, which is a little better since I can see C methods properly and can sort of guess what is going on. What does this "anonymous" mean and what can I do to prevent this? I doubt the stack trace is ACTUALLY 2 frames.
my guess is that "that's the anonymous memory-mapped region that .NET
has JITed your code into".
> For comparison, here are some other things I have found:
>
> #00 pc 00000000000a3064 /apex/com.android.runtime/lib64/bionic/libc.so (__rt_sigsuspend+4) (BuildId: 3e3c5ec517682e9d3afdceafc14d447f)
> #01 pc 00000000000608f0 /apex/com.android.runtime/lib64/bionic/libc.so (sigsuspend+52) (BuildId: 3e3c5ec517682e9d3afdceafc14d447f)
> #02 pc 0000000000287b40 /data/app/~~Y9JE4-VEbGMpV5xJIXd8Ag==/embc.zack-JXDgGUeOK9XH-CUJJYT4ow==/lib/arm64/
libmonosgen-2.0.so (suspend_signal_handler+188)
>
> Notice the proper function names present. Are these simply shipping with debug information present?
not exactly. we strip, but we keep symbol names. (for exactly this use
case. it's a relatively small fraction of the total debugging
information, and has the most direct practical use for the most
people.)
> Or is there some agreed upon method to get JUST the information needed for stack traces to print properly. We tried shipping with debug information present once and immediately got complaints about the library bloating from less than 10 MiB to over 40.
to be able to unwind through a .NET JIT frame, you'll need the .NET
implementation to do some work. (but iirc ART does just use the usual
gdb JIT interface, so if they fix/add the necessary, it'll work better
for everyone else too. it's possible it's already there, and you just
need to enable it, but that's a question for people who know something
about your .NET implementation :-) )
> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
android-ndk...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/android-ndk/fa653c95-8e85-43e6-8232-6da5a1ef0c06n%40googlegroups.com.