1813845 - add annotation with stack from crash ping

Status: NEW

(Toolkit :: Crash Reporting, enhancement)

Description

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

When Firefox crashes, the crash reporter walks the stack and adds it to the crash ping. It'd be great if we could get that information as an annotation in the crash report as well.

If we had the stack value that gets sent in the crash ping in the crash report, it'd make it easier to do the following in our crash ingestion pipeline:

1. learn more about how similar the stack in the crash ping is to the stack generated by the stackwalker: is it usually the same? is it usually different? in what scenarios is it more likely to be different?
2. debug stackwalking across the different stackwalkers
3. generate an additional crash signature for the crash report that the crash ping will likely have making it easier to hop from crash ping analysis to equivalent group of crashes in the crash report data set
4. possibly many other things!

Comment 1

[Gabriele Svelto [:gsvelto]]

(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #0)

When Firefox crashes, the crash reporter walks the stack and adds it to the crash ping. It'd be great if we could get that information as an annotation in the crash report as well.

When the minidump-analyzer tool processes a crash that's exactly what it does: it adds an annotation which is later stripped before the crash is submitted to Socorro. So from a practical perspective this would be a single-line change to the crash submission code.

If we had the stack value that gets sent in the crash ping in the crash report, it'd make it easier to do the following in our crash ingestion pipeline:

1. learn more about how similar the stack in the crash ping is to the stack generated by the stackwalker: is it usually the same? is it usually different? in what scenarios is it more likely to be different?

ATM they're different for two reasons: we use the old Breakpad-based stackwalker in the minidump-analyzer tool we ship to the clients and it doesn't have access to unwinding data on Linux and macOS, so all traces there will be done via stack-scanning, Windows uses the unwinding tables it finds locally.

2. debug stackwalking across the different stackwalkers

This will be less interesting once we get rid of the Breakpad-based stackwalker and use rust-minidump both on the client and the server but there will still be differences. More on this later.

3. generate an additional crash signature for the crash report that the crash ping will likely have making it easier to hop from crash ping analysis to equivalent group of crashes in the crash report data set
4. possibly many other things!

Assuming we'll be able to fix bug 1743983 soon we'll effectively have the same stackwalker on both ends however there might still be subtle differences between the two: the one we use in Socorro will be fed .sym files, so if there's a bug in dump_syms for example, or simply a missing symbol file it will produce a different stack than on the client. The one on the client will be fed native unwinding tables so the walker might act slightly differently, and more importantly it should have access to the unwinding tables of all the executables (including Android native libraries for example, which is very unlikely we'll ever have available as .sym files).

Comment 2

[Alex Franchuk [:afranchuk]]

We can definitely turn this on! And when bug 1743983 finally lands, we will have good stack traces on all platforms.