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

RESOLVED FIXED

Status

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: blassey, Assigned: rhelmer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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)

Updated

7 years ago
Assignee: nobody → rhelmer
Status: NEW → ASSIGNED

Comment 1

7 years ago
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

Comment 2

7 years ago
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?
(Assignee)

Comment 3

7 years ago
(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?

Comment 4

7 years ago
(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.

Updated

7 years ago
Depends on: 711973
In case the radio silence didn't already answer that for you, Tuesday is fine.
(Assignee)

Comment 6

7 years ago
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" 
"""
(Assignee)

Comment 7

7 years ago
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.
(Assignee)

Comment 9

7 years ago
(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.
(Assignee)

Comment 10

7 years ago
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.
(Assignee)

Comment 11

7 years ago
(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 :)

Comment 12

7 years ago
(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.

Comment 14

7 years ago
Shouldn't be affected, this one reprocessed data from the start of the year to Jan 17.

Comment 15

7 years ago
Given that I confirmed that they have been reprocessed, I'm just marking this one fixed, I hope that's OK.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.