Closed Bug 921569 Opened 12 years ago Closed 12 years ago

Data request for aggregate counts on the AMD crash

Categories

(Socorro :: Data request, task)

Product:
Socorro
Component:
Data request
Platform:
x86_64
Windows 7
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: away, Assigned: selenamarie)

References

Details

Attachments

(2 files)

report_20131001_20131204.csv
11.39 KB, text/csv
Details
report_130422_130522.csv
3.89 KB, text/csv
Details
AMD would like to know how often we are hitting the suspected AMD CPU issue (bug 772330 and its linked bugs) broken down by chip model. The crash signature moves around from build to build, so we've amassed a number of different bugs for this issue. Is it possible to get aggregate counts across all the known signatures? AMD is looking for: - Total number of crash reports for: AuthenticAMD family 20 model 1 stepping 0 - Total number of crash reports for: AuthenticAMD family 20 model 2 stepping 0 - Current incident rates (# issues per day, #issue per month) for either model For that last item, perhaps the peak rate may be more useful than the current rate, since it varies over time depending on whether particular builds hit the issue.
dmajor, since we're dealing with a bunch of different individual crashes, perhaps you can collate which signatures and which date ranges you're interested in?
I dug these signatures out of the linked bugs. As far as date ranges, I think we'd want as much as possible. Bug 700288 -> https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Agfx%3A%3ABaseRect%3Cint%2C%20nsRect%2C%20nsPoint%2C%20nsSize%2C%20nsMargin%3E%3A%3AUnionEdges%28nsRect%20const%26%29 Bug 714320 -> https://crash-stats.mozilla.com/report/list?signature=nsStyleContext::AddChild%28nsStyleContext*%29 Bug 722024 -> https://crash-stats.mozilla.com/report/list?signature=xul.dll%400xc584d%20|%20nsIFrame%3A%3AGetOverflowRect%28nsOverflowType%29 Bug 722025 -> https://crash-stats.mozilla.com/report/list?signature=xul.dll%400xc584d%20|%20nsHTMLScrollFrame%3A%3APlaceScrollArea%28ScrollReflowState%20const%26%2C%20nsPoint%20const%26%29 Bug 722030 -> https://crash-stats.mozilla.com/report/list?signature=nsFrame%3A%3ADisplayBorderBackgroundOutline%28nsDisplayListBuilder*%2C%20nsDisplayListSet%20const%26%2C%20bool%29 Bug 722165 -> https://crash-stats.mozilla.com/report/list?signature=xul.dll%400xc584d+|+nsAbsoluteContainingBlock%3A%3AReflow%28nsContainerFrame*%2C+nsPresContext*%2C+nsHTMLReflowState+const%26%2C+unsigned+int%26%2C+int%2C+int%2C+bool%2C+bool%2C+bool%2C+nsOverflowAreas*%29 Bug 722312 -> https://crash-stats.mozilla.com/report/list?signature=nsTableRowGroupFrame%3A%3AReflowChildren(nsPresContext*%2C nsHTMLReflowMetrics%26%2C nsRowGroupReflowState%26%2C unsigned int%26%2C bool*)&reason_type=contains&date=01%2F30%2F2012 07%3A09%3A28&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&admin=1&signature=nsTableRowGroupFrame%3A%3AReflowChildren(nsPresContext*%2C nsHTMLReflowMetrics%26%2C nsRowGroupReflowState%26%2C unsigned int%26%2C bool*) Bug 728533 -> https://crash-stats.mozilla.com/report/list?reason=EXCEPTION_ILLEGAL_INSTRUCTION&signature=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C%20nsIFrame*%2C%20nsRect%20const%26%2C%20nsDisplayListSet%20const%26%2C%20unsigned%20int%29 Bug 745515 -> https://crash-stats.mozilla.com/report/list?signature=nsBlockReflowContext%3A%3AReflowBlock%28nsRect+const%26%2C+bool%2C+nsCollapsingMargin%26%2C+int%2C+bool%2C+nsLineBox*%2C+nsHTMLReflowState%26%2C+unsigned+int%26%2C+nsBlockReflowState%26%29 Bug 771764 -> https://crash-stats.mozilla.com/report/list?signature=nsStyleSet%3A%3AGetContext%28nsStyleContext*%2C+nsRuleNode*%2C+nsRuleNode*%2C+bool%2C+bool%2C+nsIAtom*%2C+nsCSSPseudoElements%3A%3AType%2C+bool%2C+mozilla%3A%3Adom%3A%3AElement*%29 Bug 830531 -> https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A20.0a2&signature=TlsGetValue Bug 839270 -> https://crash-stats.mozilla.com/report/list?signature=nsTArray%3CtxExpandedNameMap_base%3A%3AMapItem%2C+nsTArrayDefaultAllocator%3E%3A%3AIndexOf%3CtxExpandedName%2C+txMapItemComparator%3E%28txExpandedName+const%26%2C+unsigned+int%2C+txMapItemComparator+const%26%29+|+nsStyleContext%3A%3AnsStyleContext%28nsStyleContext*%2C+nsIAtom*%2C+nsCSSPseudoEl%2E%2E%2E Bug 865701 -> https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Adom%3A%3ADocumentBinding%3A%3ACreateInterfaceObjects%28JSContext*%2C+JSObject*%2C+JSObject**%29
The crash-stats database is highly dependent on date ranges to perform efficient queries. Why don't we pick an interesting set of date ranges (the week where this caused issues for Firefox 19.0) to measure something like this? The *current* rates are not really interesting at all, since this is intermittent. Are they interested only in those two CPUs, or are they also looking for % of crashes against some other baseline?
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > The crash-stats database is highly dependent on date ranges to perform > efficient queries. Why don't we pick an interesting set of date ranges (the > week where this caused issues for Firefox 19.0) to measure something like > this? The *current* rates are not really interesting at all, since this is > intermittent. > Are you suggesting that we pick a week from one bug as an example, and count all bugs during that week (when the others were off-peak or not-yet-occured)? Or simply choose a single week from a single bug as an example of peak rate? > Are they interested only in those two CPUs, or are they also looking for % > of crashes against some other baseline? It sounds to me like it's just the absolute numbers.
Selena: can you please help dmajor with this? Ideally, before the Summit if possible.
Assignee: nobody → sdeckelmann
Needing to pull some of this data out of hbase. Getting into that now.
Aggregate data for 10/1/2013 - 12/03/2013, number of crashes per day for a couple AMD processor types
:dmajor - let me know if you need more information or need it aggregated a different way.
Flags: needinfo?(dmajor)
Flags: needinfo?(dmajor) → needinfo?(sdeckelmann)
Thanks for the update! I would be interested to see how those numbers compare to earlier in the year, when there was a lot of activity on this crash. Is it possible to run the same query for the 30 days starting 2013-04-22? (At that time, there were 19.0 crashes coming in, and the crashing 21.0 beta was released in that period too)
Report on AMD Crashes for 4/22/13 - 5/22/13.
Flags: needinfo?(sdeckelmann)
:dmajor -- anything else you'd like for this bug? Or can we close it?
I think this should be good. I'll pass these numbers along to AMD. Thanks for the help!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Ah, one more thing: are these the actual counts? Or do I need to multiply by some number to make up for partial processing?
Flags: needinfo?(sdeckelmann)
(In reply to David Major [:dmajor] from comment #13) > Ah, one more thing: are these the actual counts? Or do I need to multiply by > some number to make up for partial processing? We process 10%. Further explanation: The numbers I provided are actual counts of what we processed. However, we only process 10% of all the crashes that we receive.
Flags: needinfo?(sdeckelmann)
Okay, so I'll multiply by ten to estimate how many reports we're getting.
(In reply to Selena Deckelmann :selenamarie :selena from comment #14) > We process 10%. That's only true for the Firefox desktop release channel. On all other channels, and on all other products we process 100%. But every processed crash nowadays has a field telling what rule applied to it.
All that said, if we are only comparing volumes at different points in time, we can assume though that the split between 10% and 100% processing remains stable and therefore can ignore it.
Right, but in this case AMD wants to understand how frequently this issue occurs, so I want to give them something resembling the actual crash rate.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: