stylo: Crash in nsCSSFrameConstructor::MaybeRecreateContainerForFrameRemoval

RESOLVED FIXED in Firefox 56



CSS Parsing and Computation
13 days ago
a day ago


(Reporter: marcia, Unassigned)


(Blocks: 1 bug, {crash})

Windows 10

Firefox Tracking Flags

(firefox54 unaffected, firefox55 unaffected, firefox56 fixed, firefox-esr52 unaffected)


(crash signature)



13 days ago
This bug was filed from the Socorro interface and is 
report bp-c0d871b5-962b-47ab-ad76-d458e0170710.

Seen while looking at crash stats: 28/18 installs on Windows 10 and Linux.

One user comment: Clicking on a suggested YouTube video sometimes causes crashes while the page is transitioning
Priority: -- → P1
I suspect all these frame constructor crashes actually have the same root cause that there are some frames used after free.
bholley, do you know if we generate / destroy frames in a different way than gecko?
Flags: needinfo?(bobbyholley)
Looking at the crash report again, it seems to me that, in MaybeRecreateContainerForFrameRemoval, aFrame is valid, but inFlowFrame is nullptr (otherwise it should crash at an earlier place), which indicates that aFrame is an out-of-flow frame, but it doesn't have corresponding placeholder frame set.

There are three places which set NS_FRAME_OUT_OF_FLOW to a frame, while only one of them (CreatePlaceholderFrameFor) actually assign a placeholder frame for it.

One of the other two places is for creating continuation of an out-of-flow frame in CreateContinuingFrame, which I suspect shouldn't be causing this, because the frame is the primary frame of a content (childFrame in nsCSSFrameConstructor::ContentRemoved), which presumably shouldn't be a continuation frame.

The remaining place is nsAbsoluteItems::AddChild. But that function only has one caller (ConstructBackdropFrameFor), and from that caller, it seems we certainly set the placeholder for it. So this isn't the case.

Another possibility is that we destroy the placeholder before we destroy the out-of-flow frame itself. This in theory shouldn't happen either, because we only destroy placeholder frame in nsPlaceholderFrame::DestroyFrom, where we would destroy the out-of-flow frame if that frame is not in the subtree of aDestructRoot. Otherwise, DestroyFrom should eventually destroy the out-of-flow frame at some point.

That said, I have no idea how this can happen, then...
I can reproduce quite reliably on a private JIRA wiki instance: I open a PDF file (that's rendered by JIRA itself) and then close it to go back at the enclosing page. When I close it this crashes about 50% of the time.

Sadly I can't reproduce on Mozilla's on wiki instance on mana :( (tried several files)
Would it be possible to give one of us access to your instance to reproduce?
Flags: needinfo?(bobbyholley) → needinfo?(felash)
Actually I can't make it crash anymore at the moment :/ so I think the STR is something more involved...
Flags: needinfo?(felash)
No longer happened since 20170715100214. So this is not for bug 1371450. But anyway I am going to close this.
Last Resolved: 2 days ago
Resolution: --- → FIXED
status-firefox54: --- → unaffected
status-firefox55: --- → unaffected
status-firefox56: affected → fixed
status-firefox-esr52: --- → unaffected
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.