1389197 - Missing Windows Version in Operating System Summary

Status: RESOLVED FIXED

(Socorro :: Processor, task, P2)

Description

[Marcia Knous [:marcia]]

Attachment: Screen Shot 2017-08-10 at 2.41.23 PM.png

Today while looking at a signature I noticed the following attached screenshot.

http://bit.ly/2uKLRtW shows

Comment 1

[Peter Bengtsson [:peterbe]]

Strange. Here's one of those crashes:
https://crash-stats.mozilla.com/report/index/95534ae6-82dd-4cdb-b297-994c00170815

The 'platform' field is supposed to be set on the processed_crash but this on has none:
https://crash-stats.mozilla.com/api/UnredactedCrash/?crash_id=95534ae6-82dd-4cdb-b297-994c00170815

Comment 2

[Peter Bengtsson [:peterbe]]

(In reply to Peter Bengtsson [:peterbe] from comment #1)
> Strange. Here's one of those crashes:
> https://crash-stats.mozilla.com/report/index/95534ae6-82dd-4cdb-b297-
> 994c00170815
> 
> The 'platform' field is supposed to be set on the processed_crash but this
> on has none:
> https://crash-stats.mozilla.com/api/UnredactedCrash/?crash_id=95534ae6-82dd-
> 4cdb-b297-994c00170815

Sorry, it's "os_name" as far as the processed crash is concerned. "platform" is what's it's called in supersearch. Either way, it's in there but it's empty. An empty string.

Comment 3

[Peter Bengtsson [:peterbe]]

Will, 
Can you take a look here. I thought it'd be an easy fix but now I'm not so sure. 

I ran the processor locally to have a look how this works. The reason the `os_name` becomes an empty string is because of this: https://github.com/mozilla-services/socorro/blob/a9e892cac868aadacfcd50d7bc4e4fb893704c8e/socorro/processor/general_transform_rules.py#L53-L57

The reason is that this crash https://crash-stats.mozilla.com/api/UnredactedCrash/?crash_id=95534ae6-82dd-4cdb-b297-994c00170815 does not have much information it is .json_dump::

 "json_dump": {
    "status": "ERROR_NO_THREAD_LIST",
    "sensitive": {}
 },

However, in .additional_minidumps it points to .upload_file_minidump_browser which if you follow it *has* a nice big .upload_file_minidump_browse.json_dump.system_info

So is the problem that we're looking up the wrong json_dump when we draw information from it?

Comment 4

[Marcia Knous [:marcia]]

I see this in Android as well: https://crash-stats.mozilla.com/signature/?signature=java.lang.IllegalStateException%3A%20You%20need%20to%20use%20a%20Theme.AppCompat%20theme%20(or%20descendant)%20with%20this%20activity.%20at%20android.support.v7.app.AppCompatDelegateImplV7.createSubDecor(Unknown%20Source)#summary

Comment 5

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

There are a few curious things in the processed crash:

1. the processed_crash.crashedThread value is null

2. when stackwalker worked on upload_file_minidump, it couldn't find a crashing thread and returned ERROR_NO_THREAD_LIST

3. because of that, there's nothing in processed_crash.json_dump

4. stackwalker worked on upload_file_minidump_browser just fine


Peter suggests "So is the problem that we're looking at the wrong json_dump when we draw information from it?" I don't think that's the case. I think we should always be looking at the upload_file_minidump dump for things.

But I wonder if we can assume that the platform/os_name for all dumps is the same. If we can, then we could have OSInfoRule look at processed_crash.json_dump and if there's nothing there, try looking at the dumps in some order. Maybe that fixes the platform value for a bunch of crashes? Maybe it creates new problems because some dumps in some crashes have crazy platform/os_name values?

What's the impact of this issue? Does it affect something important such that it should get fixed this week?

Comment 6

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

Marcia: What's the impact of this issue? Does it affect something important such that it should get fixed as soon as possible?

Comment 7

[Marcia Knous [:marcia]]

Will: I think more than anything it is confusing to have a value that is empty, especially since it wasn't that way before. More important for Desktop, probably less for Android. As an end user, I want to be able to quickly see if a particular platform is affected. I think right now in some cases this makes it more difficult. But I also don't see a lot of people complaining about it.

Comment 8

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

Sounds like it'd be helpful if this were fixed, but it's not urgent. Given that, I'm going to make this a P2.

Comment 9

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

I re-read this and then looked at a bunch of crash reports that are exhibiting this issue [1]. I think in all of these cases, the crash report is junky. There's something wrong and it's missing bits. I don't think it's the case we want to assume anything, so for now I'm going to make "Unknown" a valid platform that you can search for and fix whatever is populating os_name in the processed crash to add "Unknown" if there isn't a better value.


[1] This is super hard because you can't do a super search for crash reports where platform doesn't exist or is the empty string. :(

Comment 10

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

Attachment: pr 4608: fixi bug 1389197: fix os_name to be "Unknown" and not empty string

Comment 11

[[github robot]]

Commits pushed to master at https://github.com/mozilla-services/socorro

https://github.com/mozilla-services/socorro/commit/de1a0ffea63308c29a5deee73e02bdb19940e93b
fixi bug 1389197: fix os_name to be "Unknown" and not empty string

If an os_name can't be pulled from the minidump for whatever reason,
then set it to "Unknown" which works with the webapp interface better
rather than "" which doesn't. This allows us to search for these
crashes and it makes it clearer that Socorro wasn't able to figure
out the os_name rather than who-knows-what-happened.

Also, this switches the OSInfoRule to use glom and getitem notation.

https://github.com/mozilla-services/socorro/commit/2d60e4bb0c3ea487799f2f80901a0cabc812b25e
Merge pull request #4608 from willkg/1389197-no-os-name

fixi bug 1389197: fix os_name to be "Unknown" and not empty string