1323210 - [@ IPCError-browser | PURLClassifierParent::StartClassify ] signature doesn't link to bug 1322204

Status: RESOLVED FIXED

(Socorro :: Webapp, task)

Description

[Andrew McCreight [:mccr8]]

If you look at this search, for instance:

https://crash-stats.mozilla.com/search/?build_id=20161207030204&release_channel=nightly&product=Firefox&platform=Windows&date=%3E%3D2016-12-07T00%3A00%3A00.000Z&date=%3C2016-12-13T16%3A48%3A00.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

The signature "IPCError-browser | PURLClassifierParent::StartClassify" isn't being linked to bug 1322204, which results in dupes like bug 1323082 being filed. There was some other similar bug like this filed, but I'm not sure what the bug number was.

Comment 1

[Calixte Denizet (:calixte)]

I've the same kind of issue with signature "InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | mozilla::widget::IMMHandler::HandleComposition" which is linked with bug 1304601 (where the crash signature field has been cleared) and it should be linked to bug 1300143.

Comment 2

[[DEACTIVATED] Adrian Gaudebert]

This is the same problem as with bug 1313283. We have just merged a fix to our master branch, and will be landing that soon.

When the fix is in production, I figure we might want to reprocess a bunch of crashes with signatures ending with a white space, so that they have the correct signature.

Comment 3

[Calixte Denizet (:calixte)]

The query [1] continues to return bug 1304601 (crash signature field is empty) when it should be bug 1300143.

[1] https://crash-stats.mozilla.com/api/Bugs/?signatures=InvalidArrayIndex_CRASH%20%7C%20nsTArray_Impl%3CT%3E%3A%3AElementAt%20%7C%20mozilla%3A%3Awidget%3A%3AIMMHandler%3A%3AHandleComposition

Comment 4

[[DEACTIVATED] Adrian Gaudebert]

I believe this is a matter of re-running our bugzilla cron job to backfill the data. I'm a bit worried about doing that though, because I do not know how expensive that job is. 

Lonnen or Peter, do you know if it would be fine to run the bugzilla cron job for, say, the entire month of December? That means we would pull about 7k to 8k new bugs from bugzilla and compare them with our signatures in reports.

Comment 5

[Lonnen :lonnen]

The job is not especially intense on our system, but it can tax bugzilla. It can be tricky to 'backfill' for a window in past, and demand a lot of information from Bugzilla. Have a look at the query -- https://github.com/mozilla/socorro/blob/master/socorro/cron/jobs/bugzilla.py#L23 -- you can try simulating it on your machine to get a sense for the response time and response size.

Comment 6

[[DEACTIVATED] Adrian Gaudebert]

@Calixte, the issues you're hitting are due to bugs being inaccessible because of sec permissions, and thus they cannot be added to our system. 

I have run the backfill script, I now expect that there won't be any other problem with this. If there are, let's file new bugs. :)