Open Bug 1228537 Opened 9 years ago Updated 2 years ago

about:crashes should allow to display crash signatures

Categories

(Firefox :: General, enhancement)

enhancement

Tracking

()

Tracking Status
firefox45 --- affected

People

(Reporter: sebo, Unassigned)

References

()

Details

If you want to get to know the crash signature of a bug you have to click it and wait until the crash stats page is loaded. And for old crash reports the crash stats page doesn't have any info.
This makes it cumbersome or impossible to find a crash report by signature.

Therefore the crash signature should be made available directly within about:crashes.

Possible solutions for this might be:
1. A tooltip for each link containing the signature.
2. Displaying the signatures next to the links. (Maybe behind a toggle option to display/hide all signatures.)

Sebastian
crash-stats provides a JSON REST API that could work for this, for instance:

https://crash-stats.mozilla.com/api/ProcessedCrash/?crash_id=02abb526-8acd-42e9-9c10-06d272160525&datatype=processed

The "signature" key has the signature for that crash ID.
(In reply to Sebastian Zartner [:sebo] from comment #0)
> And for old crash reports the crash stats page doesn't have any info.

This would require caching the signature (might not be a bad idea anyway, although it's important to remember that the signature can change!), and you'd need to have loaded about:crashes for this approach to work.

The problem is that 100% of crashes are not processed (processing is required to generate a signature), and processing is decoupled from submission, so this data is not available immediately upon submission.

How important is this requirement, do you frequently need to chase crashes that are expired (this would imply they were at least 6 months old?)
I would concentrate on comment 0 description of the problem, rather than necessarily the solution proposed.  For example, if you take the signature a step further and get a hold of the bug that's associated with the crash, you could organize and present by bug number.  The reports that aren't processed would be tagged as such, and you can force the processing from the interface.
I expect the body of the work to be done in bug 1276716.
(In reply to Milan Sreckovic [:milan] from comment #3)
> I would concentrate on comment 0 description of the problem, rather than
> necessarily the solution proposed.  For example, if you take the signature a
> step further and get a hold of the bug that's associated with the crash, you
> could organize and present by bug number.  The reports that aren't processed
> would be tagged as such, and you can force the processing from the interface.
> I expect the body of the work to be done in bug 1276716.

These sound like good ideas to me, I would suggest that crash-stats adds an API for this as the approach comment 1 would be slow and likely to run into rate limiting on the server side.

More desirable for this use case would be a JSON REST API that:

1) took multiple crash IDs as parameters
2) returned only the desired fields (processed_state, bug#, signature)

Triggering processing from the about:crashes UI is a good idea.
(In reply to Robert Helmer [:rhelmer] from comment #2)
> (In reply to Sebastian Zartner [:sebo] from comment #0)
> > And for old crash reports the crash stats page doesn't have any info.
> 
> This would require caching the signature (might not be a bad idea anyway,
> although it's important to remember that the signature can change!), and
> you'd need to have loaded about:crashes for this approach to work.

In which cases can the crash signature change for an already reported crash?

> The problem is that 100% of crashes are not processed (processing is
> required to generate a signature), and processing is decoupled from
> submission, so this data is not available immediately upon submission.
> 
> How important is this requirement, do you frequently need to chase crashes
> that are expired (this would imply they were at least 6 months old?)

Luckily I rather seldomly have crashes and only had a few of those old ones where I would have needed the signature, so it's not that important - or let's say low priority.

Having said that, as a user I'd expect all my crash reports to be processed automatically at some point. Unprocessed crash reports may give the impression that Mozilla doesn't care about the reports.

(In reply to Milan Sreckovic [:milan] from comment #3)
> I would concentrate on comment 0 description of the problem, rather than
> necessarily the solution proposed.  For example, if you take the signature a
> step further and get a hold of the bug that's associated with the crash, you
> could organize and present by bug number.  The reports that aren't processed
> would be tagged as such, and you can force the processing from the interface.
> I expect the body of the work to be done in bug 1276716.

Having the associated bug number(s) linking to the related report(s) would be extremely valuable. Though I agree that this may go beyond the scope of this report.

(In reply to Robert Helmer [:rhelmer] from comment #4)
> More desirable for this use case would be a JSON REST API that:
> 
> 1) took multiple crash IDs as parameters
> 2) returned only the desired fields (processed_state, bug#, signature)

Totally agree.

> Triggering processing from the about:crashes UI is a good idea.

I also agree on this. Though, as stated above, this should not replace automatic processing, it should only increase the processing priority of the clicked report.

Sebastian
(In reply to Sebastian Zartner [:sebo] from comment #6)
>...
> 
> Having the associated bug number(s) linking to the related report(s) would
> be extremely valuable. Though I agree that this may go beyond the scope of
> this report.

That's probably what we'll aim to do in bug 1276716.


> (In reply to Robert Helmer [:rhelmer] from comment #4)
> > More desirable for this use case would be a JSON REST API that:
> > 
> > 1) took multiple crash IDs as parameters
> > 2) returned only the desired fields (processed_state, bug#, signature)
> 
> Totally agree.
> 
> > Triggering processing from the about:crashes UI is a good idea.
> 
> I also agree on this. Though, as stated above, this should not replace
> automatic processing, it should only increase the processing priority of the
> clicked report.

Also likely to be worked on in bug 1276716 - it needs to be cheap to do these queries, so we'll likely need #1 and #2.
(In reply to Sebastian Zartner [:sebo] from comment #6)
> (In reply to Robert Helmer [:rhelmer] from comment #2)
> > (In reply to Sebastian Zartner [:sebo] from comment #0)
> > > And for old crash reports the crash stats page doesn't have any info.
> > 
> > This would require caching the signature (might not be a bad idea anyway,
> > although it's important to remember that the signature can change!), and
> > you'd need to have loaded about:crashes for this approach to work.
> 
> In which cases can the crash signature change for an already reported crash?


If there was an error in processing (not very common but has happened), or there's a change to the signature generation rules and it's determined that it would be useful to fix previous crashes (this is a bit more common.)

 
> > The problem is that 100% of crashes are not processed (processing is
> > required to generate a signature), and processing is decoupled from
> > submission, so this data is not available immediately upon submission.
> > 
> > How important is this requirement, do you frequently need to chase crashes
> > that are expired (this would imply they were at least 6 months old?)
> 
> Luckily I rather seldomly have crashes and only had a few of those old ones
> where I would have needed the signature, so it's not that important - or
> let's say low priority.
> 
> Having said that, as a user I'd expect all my crash reports to be processed
> automatically at some point. Unprocessed crash reports may give the
> impression that Mozilla doesn't care about the reports.


This is only the case for release crashes (by far the vast majority of crashes) - 10% was determined to be representative a few years ago, and this was before crash-stats was moved to AWS so increasing capacity was not trivial - this means increasing storage and processing capacity by ~90% in order to keep up.

Currently attempting to pull up an unprocessed crashes causes it to be processed on-demand, I am pretty sure even using the current ProcessedCrash API will do this.

However I know there have been some use cases brought up that would require 100% processing, so it's certainly a possibility in the near future. I just know that today crash-stats only processes 10% of release crashes, 100% of everything else that's recognized (and 0% is processed automatically for any unrecognized products/versions.)

 
> (In reply to Milan Sreckovic [:milan] from comment #3)
> > Triggering processing from the about:crashes UI is a good idea.
> 
> I also agree on this. Though, as stated above, this should not replace
> automatic processing, it should only increase the processing priority of the
> clicked report.


I believe this is currently the case with ProcessedCrash API as well as hitting the /report/index/{crash_id} URL, if the crash ID is in raw storage but not processed storage then it is immediately placed into the priority processing queue.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.