Closed Bug 1350888 Opened 5 years ago Closed 5 years ago

Crash in mozilla::RefreshTimerVsyncDispatcher::NotifyVsync

Categories

(Core :: Graphics, defect)

55 Branch
All
Windows
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox52 --- unaffected
firefox53 + unaffected
firefox54 + unaffected
firefox55 --- affected

People

(Reporter: marcia, Unassigned)

References

Details

(Keywords: crash, regression, Whiteboard: [gfx-noted])

Crash Data

This bug was filed from the Socorro interface and is 
report bp-5d3dadb9-084b-4ad3-8c91-071b92170326.
=============================================================

Seen while looking at crash stats - crashes started using 20170325004004: http://bit.ly/2mIkGRg

Possible regression range based on Build ID: https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=06b2530392f938ee62ade6659bdf40dee658b5cb&tochange=36f165ceceba72d12ea746313195ae35cf817778
Here to note that most of crash reports were fired from ff 54. mChildRefreshTimers was declared as nsTArray which contains the VsyncObserver object list. Array operations like Append/Remove/Clear are in main-thread while accessing NotifyVsync() is on vsync thread. Append/Remove/Clear is safe because they only do array operations. But accessing to NotifyVsync() might have problem once the object address contains in array become invalid. Since those functions all have mutex to lock to keep thread competition away, I don't have any idea in my mind at this moment how this crash happens.
this is now showing up in greater frequency on the beta channel with 53.0b10 as well. on 54.0a2 it seems to have taken off with 54.0a2 build 20170321004003 (a bit earlier as marcia noted in comment #0) with the following regression range
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?startdate=2017-03-20&tochange=0496e366a8f4d1393a8caba1db5f6d1f49da468d

the only common patch landing on 53.0b10 in common with that pushlog would be from bug 1342433...
Crash Signature: [@ mozilla::RefreshTimerVsyncDispatcher::NotifyVsync] → [@ mozilla::RefreshTimerVsyncDispatcher::NotifyVsync] [@ OOM | large | mozilla::RefreshTimerVsyncDispatcher::NotifyVsync]
Keywords: regression
OS: Windows 10 → Windows
Hardware: Unspecified → All
See Also: → 1342433
the signature has indeed gone away in 53.0rc2 after bug 1342433 was backed out.
Any ideas why comment 4 is true?
Flags: needinfo?(surkov.alexander)
(In reply to David Bolter [:davidb] from comment #5)
> Any ideas why comment 4 is true?

honestly no ideas, if that's a not false positive. I'm not sure though how exactly NotifyVsync is related to a11y at all. Anyway, bug 1342433 didn't change the interaction model: we still schedule a NotificationController::WillRefresh processing there and we are still inside nsIListenerChangeListener::ListenersChanged callback. Thus no changes I can think of that may possibly affect on NotifyVsync stuff.
Flags: needinfo?(surkov.alexander)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.