Closed Bug 788686 Opened 12 years ago Closed 11 years ago

Can we figure out how many crashes are due to bad memory?

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: mccr8, Unassigned)

Details

(Whiteboard: [js:p3])

Spun off from bug 787281. If bad test machines make Firefox very crashy, how many of our overall crashes in the wild are due to bad memory?

(File in JS because a lot of the bad machine crashes are in the GC...)
This has three or four pieces, it seems to me: Heuristics to detect that a crash is plausibly due to bad memory (e.g. look for single-bit errors in pointers); statistical reporting back to Moz (Telemetry seems like the obvious place to put it); reporting the suspicion to the affected user, perhaps with an explicit "push this button to do a memory test" option; weeding out "uninteresting" crash and bug reports caused by bad RAM.
On a related note, a question I've often wondered is: what percent of our crashes come from users whose browser frequently crashes (for whatever reason).  Once we know a user's browser is in this category of frequent-crashers, we could prescribe a slew of escalating fixes (run memory checker, turn off all binary extensions, turn off all addons, about:support:reset, clean reinstall).

This data would also be useful on our end from a metrics perspective: right now we watch the crash-rate, but it seems like it could also be useful to be able to watch the sub-aggregate crash rates for "crashy users" vs. "non-crashy users".
Whiteboard: [js:p3]
I'm going to say "No", though I think FHR may help with questions of what % of crashes come from users that crash a lot.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.