1702520 - Empty minidumps should not get hashed

Status: NEW

(Toolkit :: Crash Reporting, enhancement)

Description

[Jeff Muizelaar [:jrmuizel]]

It looks like when we have an empty minidump we get a minidump_sha256_hash ofe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

https://crash-stats.mozilla.org/search/?minidump_sha256_hash=%3De3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855&date=%3E%3D2021-03-25T14%3A14%3A00.000Z&date=%3C2021-04-01T14%3A14%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=minidump_sha256_hash#crash-reports

It would be better if we left this field empty in this case.

Comment 1

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

So there are a couple cases here:

• no minidump at all -- these get no hash
• the minidump is an empty file -- these get the e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 hash

I think we want to distinguish these two. I think the second one suggests a problem when crash reporting that we want to be able to pick out. I'm pretty sure the last time I checked, that the crash ping data has hashes for the "minidump is an empty file" case.

I think I'd want to know:

1. What do crash pings have in the "empty minidump" case and in the "no minidump at all" case?
2. Do we need to be able to search for crash reports that have an empty minidump and thus need some indicator for that?

Jeff: When you say "better", what're you thinking? Better in what way? Easier to distinguish in the Crash Stats UI or something else?

Comment 2

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

Also, the minidump hash is computed by Socorro--not the crash reporter client. So I think this might be in the wrong product depending on what the actual issue is.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

I agree that it could be useful to distinguish the two cases. Maybe it's best to just leave as it is and just be aware that it can happen. Do we record the reasons that it happens?

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

Also, the minidump hash is computed by Socorro--not the crash reporter client. So I think this might be in the wrong product depending on what the actual issue is.

We get the hash in crash telemetry too so it looks like it's computed in both places.

Comment 4

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

Gabriele: Any idea if we know why we get empty minidump files or record that information somewhere?

Comment 5

[Gabriele Svelto [:gsvelto]]

Only guesses at the moment: we ran out of memory so badly that we couldn't write out the minidump, or there was no more space on the user's drive to write it out. A contributor added error reporting in bug 1666733 but it only works in the brand new oxidized minidump writer and that only works on Linux x86/x86-64 which is a platform where we almost never get those empty minidumps. We'll get a better idea of the issue when we make it work for ARM/AArch64 on Android which is were they happen the most.

Comment 6

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

One of the things I want to do is document the fields in the processed crash better with lineage (where'd this data come from? how is it processed/normalized?) and commentary (ex. Fenix build ids are structured differently than Firefox buildids.). This would be a perfect example of an oddity about this field that we'd want to document.

Will Lachance is leading this effort in Data Org with Telemetry fields. You can see an example of what they're putting together here: https://dictionary.protosaur.dev/apps/fenix/metrics/about_page_privacy_notice_tapped

I want to wait a little longer to see how that process turns out and then I'll write up a bug in Socorro to set up the same system with processed crash data.

Going back to this issue, I'm inclined to keep hashing empty minidumps given that we have hashes in the crash ping data and the fix here is to document the oddity in a findable place.

Would that be ok?