Closed Bug 1703717 Opened 14 days ago Closed 13 days ago

Crash on address 0x88 in mozilla::AnimationEventInfo::AnimationEventInfo


(Core :: Gecko Profiler, defect, P2)




89 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox87 --- unaffected
firefox88 --- unaffected
firefox89 --- fixed


(Reporter: sfink, Assigned: gerald)




(Keywords: regression)


(1 file)

(copied from bug 1701524 comment 4)

I think I might be getting a crash from bug 1701524 on try [1] when I push with --gecko-profile. My guess is that aAnimation->GetOwner() is returning nullptr when generating a profile marker [2]?



Regressed by: 1701524

Thank you for the report. I'll prepare a fix.

Assignee: nobody → gsquelart
Severity: -- → S3
Priority: -- → P2
Pushed by
Check for null aAnimation->GetOwner() before dereferencing - r=emilio

Sorry, and thanks for reporting and fixing it!

How can we be in a situation where we have an animation tick but the animation doesn't have an owner window? Is it just unlucky timing with a window that has already been closed, or could this be pointing to a more serious bug? We have seen multiple times profiles where composition happens at 60Hz as if there was an animation, but there's no animation (ie. bug 1690673), and the only way to get out of this state is to close the browser window. Unfortunately, no known steps to reproduce.

Flags: needinfo?(emilio)
Closed: 13 days ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Looking a bit at the code, it seems it may happen if the page is detached from the docshell or the page is navigated away. Seems this should be trivially hittable if you window.close() during a refresh driver tick or somesuch.

bug 1690673 is about the compositor and not main-thread ticks, if I'm reading bug 1690673 comment 2 correctly.

Flags: needinfo?(emilio)

Set release status flags based on info from the regressing bug 1701524

You need to log in before you can comment on or make changes to this bug.