598160 - All crashes on the top crasher report seem to have the plugin icon (except for 3rd party dlls)

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[LegNeato]

When I go to http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.6.10, even crashes I know are not plugin crashes are getting the plugin (lego-ish) icon.

This seems to have happened after the rollback last week. I'm not sure if it is just a UI display issue or if it is the way the crashes are being marked.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I noticed this after the rollback, too, for a few of Camino's topcrashes (it's not nearly as confused as Firefox's), and I'd been searching around to try and figure out what the icon was and what it meant (title attribute, anyone?): https://crash-stats.mozilla.com/topcrasher/byversion/Camino/2.0.4

Comment 2

[Laura Thomson :laura]

Ryan, can you take a look please?

Comment 3

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

We found a number of minor data discrepancies when we rolled out 1.8.  I'm wondering if the data collected during that window might have be affected the results?

Can you tell me if this page, which shows top crashing signatures for the last day
http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.6.10&range_value=1&range_unit=days&date=09%2F21%2F2010+10%3A00%3A00&query_search=signature&query_type=exact&query=&build_id=&process_type=any&hang_type=any&do_query=1

Looks more correct than the same query extended to include 7 days of data (including the data that we collected while 1.8 code had been in production):
http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.6.10&range_value=7&range_unit=days&date=09%2F21%2F2010+10%3A00%3A00&query_search=signature&query_type=exact&query=&build_id=&process_type=any&hang_type=any&do_query=1

Upon first glance there are fewer icons in the query signatures in the last day.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FWIW, when comparing https://crash-stats.mozilla.com/topcrasher/byversion/Camino/2.0.4/3 to https://crash-stats.mozilla.com/topcrasher/byversion/Camino/2.0.4,  the plug-in icons have vanished from the signatures that had them in the 7-day report.

Comment 5

[LegNeato]

(In reply to comment #3)
> We found a number of minor data discrepancies when we rolled out 1.8.  I'm
> wondering if the data collected during that window might have be affected the
> results?
> 
> Can you tell me if this page, which shows top crashing signatures for the last
> day
> http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.6.10&range_value=1&range_unit=days&date=09%2F21%2F2010+10%3A00%3A00&query_search=signature&query_type=exact&query=&build_id=&process_type=any&hang_type=any&do_query=1
> 
> Looks more correct than the same query extended to include 7 days of data
> (including the data that we collected while 1.8 code had been in production):
> http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.6.10&range_value=7&range_unit=days&date=09%2F21%2F2010+10%3A00%3A00&query_search=signature&query_type=exact&query=&build_id=&process_type=any&hang_type=any&do_query=1
> 
> Upon first glance there are fewer icons in the query signatures in the last
> day.

Yes, the first one looks correct and the second not so much (though I don't know if I am qualified to do a definitive review). Specifically, this crash:

nsChromeTreeOwner::OnLocationChange(nsIWebProgress*, nsIRequest*, nsIURI*)

isn't a plugin crash. On the first link, it shows w/o the icon (correct) and on the second the icon is there (incorrect).

Comment 6

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Something that has thrown me for a bit of a loop when working on Bug 562216 is that going into the bug I expected most crash signatures to either always be a plugin crash or to always be a browser crash. However, what I've noticed when digging into the data is that this is not always the case.

For example, the signature 'UserCallWinProcCheckWow' had 391 crashes during a 1 hour period on October 8th for Firefox 3.6.10 on Windows NT 5.1.2600 Service Pack 3.  3 of those crashes were logged as a process type of 'plugin' whereas the other 388 crashes were logged as a process type of null.  

For that same signature, over a 2 week period (looking at the snapshot we have on stage), 162,594 crashes were logged with a process_type of null, while 407 crashes were logged with a process_type of 'plugin'.

This is the case with other signatures as well.

For the discrepancies between the 3 day and 7 day windows, what we're probably seeing in the 7 day window is the anomaly of 1 crash for a particular signature being recorded as having a process type of 'plugin', while all of the other crashes associated with that signature were not recorded with that process type.

I'm assuming this is the issue with the signature -
nsChromeTreeOwner::OnLocationChange(nsIWebProgress*, nsIRequest*, nsIURI*)

Comment 7

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

I believe this issue has been largely resolved in Bug 562216 and the remaining issues will be resolved in duplicate logic which will be removed in Bug 604740.  Please re-open if this is still an issue.