Unable to get Java Stack Trace:

[Pradeep H]

Hi,

For our chromium based application we only get below stack trace for startup crashes. Which actually points to logging.cc in C++ code. 

When we replicate that crash we can see in logcat that a java stack trace is also generated for crash which exactly points out where the crash happened. 

Because of this we are unable to figure out most of the crashes reported in Play Console. Can anybody point out what should be done so that Java Stack Trace also gets reported in Play Console instead of just the below logs.

backtrace: #00 pc 00000000025511a0 /data/app/xxxxx- 0WXu9SHQLZBa1G6aQqZW7w==/base.apk!lib/arm64-v8a/crazy.libchrome.so (offset 0x65e000)

Thanks,

Pradeep

[Torne (Richard Coles)]

On Mon, 21 Mar 2022 at 21:36, Pradeep H <h.pra...@gmail.com> wrote:

Hi,

For our chromium based application we only get below stack trace for startup crashes. Which actually points to logging.cc in C++ code. 

When we replicate that crash we can see in logcat that a java stack trace is also generated for crash which exactly points out where the crash happened. 

Because of this we are unable to figure out most of the crashes reported in Play Console. Can anybody point out what should be done so that Java Stack Trace also gets reported in Play Console instead of just the below logs.

In general this is not possible as far as I'm aware. The Play Console only reports specific information provided by the Android system. When a native crash occurs, that information is solely derived from the tombstone generated by debuggerd at the time of the crash, and does not include any log messages.

It's only possible to see a Java stack trace when the process crashes due to an uncaught Java exception that's handled by the VM, and we can't do this at the JNI boundary. In a few specific cases (mostly in WebView) we carefully propagate the Java exception through native code and back to Java so that it's reported in this way to make issues easier to debug, but this requires special implementation care at each place where native code calls into Java and can't be easily generalized, so it's not practical for all the callsites in Chromium to work this way.

If you want more detailed crash information, you will need to handle crash reporting yourself (e.g. using Crashpad, as Chrome and WebView do), rather than relying on the Play Console's crash reporting mechanisms, which will be much more complex and require your own backend infrastructure to receive crash reports.

One thing you can do to make these reports somewhat more helpful, though, is to set `exclude_unwind_tables=false` in your GN arguments when building your release binaries. This will allow a full native stack trace to be generated with more than one stack frame, which may give you enough context to understand what happened even without the Java exception (it will at least tell you what native code made the JNI call to Java). However, this will significantly increase the size of your build - this adds ~16MB to our binaries last I looked.