RDD crashes can still spam crash reports
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
People
(Reporter: jld, Assigned: alwu)
References
(Blocks 1 open bug)
Details
In theory, bug 1761942 prevented the RDD process from getting into an endless loop of crashing and restarting. But, I still see bugs where that kind of crash/restart loop appears to be happening: most recently, bug 1995035, which was flagged as a topcrash because of 6k crashes from only 18 distinct install times (and 3k of those crashes all having the same install time).
I tried reproducing this locally, by commenting out these lines and navigating to a local .mp4 file. (I assume I could also have inserted a MOZ_CRASH somewhere relevant instead, but I happen to know that reliably crashes Mesa on Nightly on my system.) The video plays, but the RDD process crashes in the background, once. However, if I reload the page, I get a new crash, and that repeats as many times as I reload. So, one imagines a Nightly user browsing videos, not realizing anything is wrong because the videos are playing, and sending a crash report for each video. It's not exactly a crash loop, but it's not ideal, and I think it explains what I'm seeing on crash-stats.
Maybe there should be some kind of global limit on RDD crashes before the RDD process is turned off for the rest of the session, or a rate limit, or something along those general lines? Alternately, if there's a way to throttle the crash submissions, that might also be an option, but it seems less good to just have processes crash constantly and ignore it.
I think :alwu might be the best person to ask here - would you have any thoughts?
|
Assignee | |
Comment 2•2 months ago
|
||
Maybe there should be some kind of global limit on RDD crashes before the RDD process is turned off for the rest of the session, or a rate limit, or something along those general lines? Alternately, if there's a way to throttle the crash submissions, that might also be an option, but it seems less good to just have processes crash constantly and ignore it.
Sounds fair. Our current limitation isn’t global — it’s applied per decoder. So it’s definitely possible for too many crash reports to be sent from the same device.
Description
•