1541120 - [tracker] improve signature generation for java stack traces

Status: NEW

(Socorro :: General, enhancement, P3)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

Incoming crash reports from Rust/C/C++ code will include a minidump. During processing, minidump-stackwalk walks the stack in the minidump, symbolicates the frames in the stacks, and adds a json blob to the processed crash with stack trace structures in it.

Later in the processing pipeline, the signature generation rule will kick off, look at the json blob and generate a signature using the symbolicated frames and a bunch of processing around symbols-to-skip, sentinels, and all that.

Incoming crash reports from Java code are completely different. The Java stack trace is added as a string to the JavaStackTrace field. There's little to no information for those frames. Signature generation for Java stacks pretty much just look at the exception and the line it happened on. There's no processing, no symbols-to-skip, no sentinels, etc.

This tracker covers gauging interest in redoing signature generation for Java crash reports and if there's sufficient interest, figuring out how it should work. This might involve changing the crash reporter for Java crashes such that it includes more information to work with.

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

Making this a P3 for now--I can't tell if it's important to anyone else or not.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

As a work around create a super search that finds the interesting crashes and then facet on the java stack trace. Example:

https://crash-stats.mozilla.org/search/?java_stack_trace=~ArrayIteratorKt.throwNpe&build_id=%3E%3D20200720000000&product=Fenix&_facets=signature&_facets=java_stack_trace&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-java_stack_trace

The line numbers shard this a bit more than I would like but otherwise it looks fairly usable.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

I spent a bunch of time thinking about this today and I think any work we can do here should be blocked on getting a structured form of the Java stack trace.

I wrote up an issue in the android-components project for that: https://github.com/mozilla-mobile/android-components/issues/8653

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

Update on this. All work on it has stalled out because while it has been a problem, there didn't seem to be much interest in helping me figure out how we wanted it to work. Then I moved on to more pressing projects.

In 2021, I started a proposal with some use cases that we need to think around.

https://docs.google.com/document/d/1VUqiulo-NoAouz8XHfOuvEqyHAZCL6P3z5LOPISZmYM/edit

When we come back to this, we can look at that draft proposal document for the use cases it talks about, update it, and go from there.

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

We should also think about Java crash reports that don't have a JavaStackTrace, a JavaException, or a minidump. For Java crash reports, there may be other information in the annotation data that is useful to include. Maybe something like CrashType.