Closed Bug 1396001 Opened 7 years ago Closed 7 years ago

mdsw_status_string not returned in ProcessedCrash api

Categories

(Socorro :: General, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

References

Details

Attachments

(1 file)

In the processed_crash, there's a "mdsw_status_string" field. This field tells us what happened during stackwalking: https://github.com/mozilla-services/socorro/blob/978522f386b08d09b265c7c3401f84e1602b48c3/socorro/processor/breakpad_transform_rules.py#L184 That then gets used in signature generation: https://github.com/mozilla-services/socorro/blob/978522f386b08d09b265c7c3401f84e1602b48c3/socorro/processor/signature_utilities.py#L606 However, this field is not included in the ProcessedCrash API: https://github.com/mozilla-services/socorro/blob/978522f386b08d09b265c7c3401f84e1602b48c3/webapp-django/crashstats/crashstats/models.py#L585 This is problematic because we can't take a crash id, fetch the publicly-available raw and processed crash data from -prod, and then run signature generation on it and produce the same signature. This bug covers figuring out whether it's ok to add that field to the public API and adding it.
Peter, Adrian: Any idea why mdsw_status_string isn't available in the ProcessedCrash API? It's not available in super search, either. As near as I can tell, the data is uninteresting. Seems like it comes from the breakpad code. Possible values I've seen: * OK * ERROR_NO_MINIDUMP_HEADER * ERROR_NO_THREAD_LIST You can see them here: https://crash-stats.mozilla.com/search/?signature=%5EEMPTY&product=Firefox&date=%3E%3D2017-08-01T16%3A14%3A49.000Z&date=%3C2017-09-01T16%3A14%3A49.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
Oops--meant to tag Peter and Adrian with a needsinfo for comment #1.
Flags: needinfo?(peterbe)
Flags: needinfo?(adrian)
Note that the hardcoded list (in models.py) of API_WHITELIST is a thing that needs to disappear. The truth should be that super_search_fields.json (aka. super_search_fields:Fields). So that's that. A refactoring issue. If your question is whether it's *safe* to expose it in the whitelist, I can't confidently answer it any better than you. Perhaps best to redirect that question to Ted. If those 3 values you've listed are the only ones you've seen, I think the only reason it's not already whitelisted is simply because of time or because nobody's wanted it before. The only reason we have a whitelist is to add inertia so that we don't accidentally expose something we haven't considered making public yet.
Flags: needinfo?(peterbe)
My recommendation is to ignore https://bugzilla.mozilla.org/show_bug.cgi?id=1100352 for now and just make a PR that adds it to FIELDS and have Ted review it.
Socorro exposes this information in the signature already. I'm thinking mdsw_status_string is ok to add to the ProcessedCrash API. Ted: Does that sound ok? Any aversion to this?
Flags: needinfo?(adrian) → needinfo?(ted)
This is totally fine. There are a fixed list of possible values that are just stringified versions of Breakpad error constants: https://github.com/mozilla-services/socorro/blob/978522f386b08d09b265c7c3401f84e1602b48c3/minidump-stackwalk/stackwalker.cc#L859
Flags: needinfo?(ted)
Awesome! Grabbing this to do today. Peter: I'll think about bug #1100352--that seems handy to do especially now that we've got that data in a big file.
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: