Closed Bug 718006 Opened 13 years ago Closed 13 years ago

Please reprocess FennecAndroid crash reports with libxul.so or an empty signature from the last 2 weeks

Categories

(Socorro :: General, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: blassey, Assigned: rhelmer)

References

Details

Attachments

(1 file)

the socorro update that is happening today adds libxul.so to the skip list. To get useful data sooner, I'd like to reprocess all reports from this year (1/1/12) that either have libxul.so as its signature or an empty signature.
Assignee: nobody → rhelmer
Status: NEW → ASSIGNED
Just as a note, the empty signatures are in there because those have come into FennecAndroid also with a bug that has been fixed in 2.4: <lars> KaiRo: the empty signatures are from Java crashes with degenerate java stacks. The problem will be addressed tomorrow in the push of 2.4. Bug 712737 corrects the problem. <lars> they're listed as empty in the database because the calculated signature is too long for the database field
Oh, and I guess we need to reprocess some aggregation based on the changed signatures as well, right? Rob, is this in your plans for this as well?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > Oh, and I guess we need to reprocess some aggregation based on the changed > signatures as well, right? Rob, is this in your plans for this as well? Hmm it wasn't but is now :) Not sure if we'll have time today, is backfilling the reports on Tuesday ok or does it need to be done today?
(In reply to Robert Helmer [:rhelmer] from comment #3) > Not sure if we'll have time today, is > backfilling the reports on Tuesday ok or does it need to be done today? I guess the mobile folks (blassey/nhirata) need to answer that. The custom reports I'm usually looking at myself don't profit from any reprocessing anyhow.
Depends on: 711973
In case the radio silence didn't already answer that for you, Tuesday is fine.
Ok going to do this now, just tested on staging: """ # get uuids psql -h $databaseHost -U breakpad_rw $databaseName -c "copy (select uuid from reports where date_processed >= '2012-01-01' and date_processed <= CURRENT_DATE and product = 'FennecAndroid' and (signature is NULL or signature like 'libxul.so%')) to stdout" > bug718006.csv # insert to priority processing cat bug718006.csv | psql -h $databaseHost -U breakpad_rw $databaseName -c "copy priority_jobs from stdin" """
BTW I realize comment 6 could be done just in SQL, but I like keeping the copy of UUIDs which will be changed, just in case.
Rob, Looks fine to me.
(In reply to Robert Helmer [:rhelmer] from comment #6) > Ok going to do this now, just tested on staging: > > > """ > # get uuids > psql -h $databaseHost -U breakpad_rw $databaseName -c "copy (select uuid > from reports > where date_processed >= '2012-01-01' > and date_processed <= CURRENT_DATE > and product = 'FennecAndroid' > and (signature is NULL or signature like 'libxul.so%')) to stdout" > > bug718006.csv > > # insert to priority processing > cat bug718006.csv | psql -h $databaseHost -U breakpad_rw $databaseName > -c "copy priority_jobs from stdin" > """ BTW typo in there, correct table name is "priorityjobs". Anyway this is going now, 1545 crashes inserted to priorityjobs queue.
Attached file modified crash IDs
Processing is done, can someone confirm that it had the intended effect? Attached are the crash IDs (UUID aka OOID) reprocessed.
(In reply to Robert Helmer [:rhelmer] from comment #10) > Created attachment 589293 [details] > modified crash IDs > > Processing is done, can someone confirm that it had the intended effect? > > Attached are the crash IDs (UUID aka OOID) reprocessed. Ping? Can someone please check that reprocessing worked? I'll go ahead and backfill the data today if I don't hear anything back, but it would be nice to make sure it actually will change anything :)
(In reply to Robert Helmer [:rhelmer] from comment #10) > Processing is done, can someone confirm that it had the intended effect? As nobody else replied, I took a look: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=ALL%3AALL&range_value=2&range_unit=weeks&date=01%2F14%2F2012+00%3A00%3A00&query_search=signature&query_type=contains&query=libxul.so&reason=&build_id=&process_type=any&hang_type=any&do_query=1 looks like reprocessing worked and applied the skiplist correctly. And the (emty signature) is gone as well - unfortunately mostly just replaced with "EMPTY: java stack not in expected format" as we learned and just fixed with 2.4.1 now. Checking a random sample of the OOIDs in the attachment confirms that.
I just reprocessed Fennec/FA crashes since 1/25 for version 11.0a1 and later last night, per request of Kairo. Not sure if this bug is affected by that.
Shouldn't be affected, this one reprocessed data from the start of the year to Jan 17.
Given that I confirmed that they have been reprocessed, I'm just marking this one fixed, I hope that's OK.
Status: ASSIGNED → RESOLVED
Closed: 13 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: