1380125 - stylo: Crash in nsCSSFrameConstructor::MaybeRecreateContainerForFrameRemoval

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Marcia Knous [:marcia]]

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

Seen while looking at crash stats: http://bit.ly/2v9EZa9. 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

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

I suspect all these frame constructor crashes actually have the same root cause that there are some frames used after free.

Comment 2

[Xidorn Quan [:xidorn] UTC+11]

bholley, do you know if we generate / destroy frames in a different way than gecko?

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

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...

Comment 4

[Julien Wajsberg [:julienw]]

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)

Comment 5

[Bobby Holley (:bholley)]

Would it be possible to give one of us access to your instance to reproduce?

Comment 6

[Julien Wajsberg [:julienw]]

Actually I can't make it crash anymore at the moment :/ so I think the STR is something more involved...

Comment 7

[Hiroyuki Ikezoe (:hiro)]

No longer happened since 20170715100214. So this is not for bug 1371450. But anyway I am going to close this.