1745816 - strip leading 0s in addresses in signature generation

Status: RESOLVED FIXED

(Socorro :: Signature, task, P2)

Description

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

When signature generation doesn't have a symbol, it degrades to module@address.

When it's using frame data from breakpad stackwalker, the addresses aren't 0-padded. For example, 0x32ec0.

When it's using frame data from rust-minidump minidump-stackwalk, the addresses are 0-padded. For example, 0x0000000000032ec0.

Thus signatures that have frames that don't have symbols will change when we switch to minidump-stackwalk.

This bug covers figuring out what to do about that.

Comment 1

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

I think we want signature generation to produce the same signature for all three of these scenarios:

1. breakpad stackwalker generated output: this covers all the crash reports we've processed so far for which we have signatures which may have related bugs
2. rust minidump-stackwalk generated output: this covers all the new crash reports we're going to process going forward after we switch; it also covers crashes in Firefox CI once I get the signature generation API working
3. crash pings symbolicated with Eliot: this covers all the crash ping data

I have a script that can build a stack from a crash report that's like what we get from crash pings. I symbolicated that with the symbolication API, then (because everything is terrible), I translated that to a signature generation API request and ran that through signature generation.

Stage is running rust-minidump minidump-stackwalk.

Prod is running breakpad stackwalker.

Thus we can look at bp-dde73f3d-a4c9-4b5d-80a9-642590211212 and get:

signature data source	signature
breakpad stackwalker output	AppleGVA@0x32ec0
rust-minidump minidump-stackwalker output	AppleGVA@0x0000000000032ec0
rube goldberg script with symbolication and signature generation APIs	AppleGVA@0x32ec0

We really want signatures to be the same across all three of these groups because we're tired and we're weary and why deal with this, too.

Given that, I think we need to strip the leading 0s converting addresses (which are strings) from things like 0x0000000000032ec0 to things like 0x32ec0.

Gabriele, Aria: Any objections to this?

Comment 2

[Aria Beingessner [:Gankra]]

The primary argument for 0-padding was (iirc) that it made supersearch sorting work better. Presumably signatures do not have the same concern? If so, this seems fine.

Comment 3

[Gabriele Svelto [:gsvelto]]

Fine for me too, we don't need sorting in signatures and them being shorter is a plus when we're missing symbols.

Comment 4

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

Awesome-sauce! I will strip leading 0s with reckless abandon.

Comment 5

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

Attachment: pr 5944: bug 1745816: strip leading zeros for addresses in signature generation

Comment 6

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

willkg merged PR #5944: "bug 1745816: strip leading zeros for addresses in signature generation" in f288096.

Comment 7

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

This went to production 8 hours ago or so in bug #1745983. Marking as FIXED.