Content process abort [@ RenderFrameParent::BuildLayer]

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Felipe, Assigned: cjones)

Tracking

Trunk
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec2.0b4+)

Details

(Whiteboard: [e10s])

Attachments

(3 attachments)

After staying up for a few seconds, and sending some mouse events to the content process (not sure if this is needed or not), the content process aborts at this check:

220   NS_ABORT_IF_FALSE(!mContainer ||
221                     IsTempLayerManager(aManager) ||
222                     mContainer->Manager() == aManager,
223                     "retaining manager changed out from under us ... HELP!");

http://mxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp#220

I have layers.accelerate-none and gfx.direc2d.disabled both set to true. This was not happening on a tree from Nov 12.
Regressed by bug 595277, 99.9999% sure.  Bisect would be very useful.  If I understand that bug correctly, it shouldn't have affected accelerate-none.
(More specifically: shouldn't have *needed* to affect accelerate-none.)
Posted file stack
Yep, I bisected and indeed bug 595277 is what caused this. This is a stack with the crash on the parent process. Bas, any idea what would cause this? What other information can I get that would be helpful? I don't have many ideas on how to debug this.

(fyi this is a e10s-enabled FF running on windows)
Blocks: 595277

Updated

9 years ago
Summary: Content process abort @ RenderFrameParent::BuildLayer → Content process abort [@ RenderFrameParent::BuildLayer]
Hrm, I've got some ideas that I can investigate. I think I might know what's happening, but I'm not sure why it would break anything.
My guess is that those patches have the windows widget backend create an initial basic layer manager, then later the "real" layer manager, regardless of the value of layers.accelerate-none.  There's nothing inherently wrong with that, it's just that our IPC backend doesn't yet have code to deal with changing layer managers.

If that's the case, and if it's not too hard, a happy compromise/workaround might be to re-use the initial basic layer manager as the "real" one when not using d3d, since creating a second basic layer manager is pure overhead.
fwiw, from what I understood it seems that the reason that this bug happens even when layers.accelerate-none=true is that even for that case, when the 5s timer kicks in the current layer manager is destroyed and a new one is created (another basic one).

Updated

9 years ago
tracking-fennec: --- → 2.0b4+
Assignee: nobody → jones.chris.g
Attachment #503016 - Flags: review? → review?(bas.schouten)
Also fixes pref obsoleted by bug 623446.
Attachment #503041 - Flags: review?(mark.finkle)
Attachment #503016 - Flags: review?(bas.schouten) → review+
Attachment #503041 - Flags: review?(mark.finkle) → review+
http://hg.mozilla.org/mozilla-central/rev/21c9b822e069

mfinkle landed a modified version of the m-b patch earlier today to work around another bug, so I'm going to go ahead and close this out.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.