731653 - Bugs for some signatures are not showing up in Socorro

Status: VERIFIED FIXED

(Socorro :: General, task)

Description

[Marcia Knous [:marcia]]

I mentioned this to KaiRo today, and filing today because I am seeing this more regularly. I notice when looking at https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/11.0b4/7 that several of the signatures in the list are not associated with a bug despite the fact they are already filed. Examples:

Bug 727624
Bug 729507

There are a few more, but I would have to hunt them down.

Comment 1

[Marcia Knous [:marcia]]

Bug 720390 is another one I just encountered.

Comment 2

[Robert Kaiser]

I think Lonnen knows the signature<->bug connection code best, CCing him.

Comment 3

[Robert Kaiser]

https://crash-stats.mozilla.com/report/list?signature=_chkstk%20|%20nsCacheService%3A%3AUnlock%28%29 fails to be connected to bug 725945 now, and https://crash-stats.mozilla.com/report/list?signature=CrashInJS%20|%20JS_AbortIfWrongThread fails to be connected to bug 715757.

Those signatures are pretty new, as they did only appear due to yesterday's skiplist additions.

Comment 5

[Lonnen :lonnen]

unduping. This is more likely a problem with the cron.

Comment 6

[Laura Thomson :laura]

Sorry, I should have read more closely!

Comment 7

[Scoobidiver (away)]

If you can't fix it before 2.5.1, you should run the cron manually each day, because there's a risk to have several bugs for one crash signature. Indeed, the matching bug doesn't appear in crash queries AND in crash reports.

Comment 8

[Lonnen :lonnen]

The cron that handles these associations is run hourly. It appears that it hasn't been able to complete a run for a few days.

On 02-29-2012 at 17:11 we stopped getting results from the buglist.cgi? query that powers the bug association cron. There is no explicit error logged, but from what is in the logs it looks like an error is being silently caught, because the code cleanup `finally` block executes right after the query is supposed to execute.

This repeats every hours until 03-01 at 00:11, when instead of the anticipated csv, the query returns an HTML page. The same page can be loaded by manually checking: 

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;bugidtype=include;chfieldfrom=2012-03-01;chfieldto=Now;chfield=[Bug%20creation];chfield=resolution;chfield=bug_status;chfield=short_desc;chfield=cf_crash_signature;order=Importance;columnlist=bug_id%2Cbug_status%2Cresolution%2Cshort_desc%2Ccf_crash_signature;ctype=csv;list_id=2512000

This causes a more explicit error. I'm not sure why the behavior changed, but will dig more in the morning.

Comment 9

[Robert Kaiser]

(In reply to Chris Lonnen :lonnen from comment #8)
> On 02-29-2012 at 17:11 we stopped getting results

Was that when we pushed the 2.4.4 release or is that a coincidence?

> This repeats every hours until 03-01 at 00:11, when instead of the
> anticipated csv, the query returns an HTML page. The same page can be loaded
> by manually checking: 
> 
> https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;
> bugidtype=include;chfieldfrom=2012-03-01;chfieldto=Now;
> chfield=[Bug%20creation];chfield=resolution;chfield=bug_status;
> chfield=short_desc;chfield=cf_crash_signature;order=Importance;
> columnlist=bug_id%2Cbug_status%2Cresolution%2Cshort_desc%2Ccf_crash_signature
> ;ctype=csv;list_id=2512000

This complains about missing search parameters, but I thought that changed fields were search parameters, did we always send this query?
Glob, did Bugzilla change in the recent few days to suddenly return an error here?

Comment 10

[:glob ✱]

i'd say bug 731664 would be the most likely culprit here.
weird thing is when i point the same query to my dev system, it works :|

i've investigate further.

Comment 11

[:glob ✱]

i've been able to replicate this issue, i've raised bug 732409, and should attach a fix there soon.  sorry about this :(

Comment 12

[Robert Kaiser]

(In reply to Marcia Knous [:marcia] from comment #0)
> Bug 727624

Works now.

> Bug 729507

Works now.

(In reply to Marcia Knous [:marcia] from comment #1)
> Bug 720390 is another one I just encountered.

That one has [] in its name, this is a separate (and difficult) case handled by bug 703102.

(In reply to Robert Kaiser (:[e-mail]) from comment #3)
> https://crash-stats.mozilla.com/report/
> list?signature=_chkstk%20|%20nsCacheService%3A%3AUnlock%28%29 fails to be
> connected to bug 725945 now, and
> https://crash-stats.mozilla.com/report/
> list?signature=CrashInJS%20|%20JS_AbortIfWrongThread fails to be connected
> to bug 715757.

Those work now.


Due to that assessment, I'm closing this bug as FIXED by bug 732409.

Comment 13

[Lonnen :lonnen]

It looks like the Bugzilla cron began completing successfully again last night. Putting back in the milestone for QA to verify.

Comment 14

[Matt Brandt [:mbrandt]]

The cron continues to appear to be working correctly. Closing this out as qa verified. Please let us know if this issue crops up again.