617860 - Content process abort [@ RenderFrameParent::BuildLayer]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(More specifically: shouldn't have *needed* to affect accelerate-none.)

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Attachment: 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)

Comment 4

[Bas Schouten (:bas.schouten)]

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.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

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

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Don't throw out basic layer managers if we're just going to recreate them anyway

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Disable GPU rendering for fennec-on-windows

Also fixes pref obsoleted by bug 623446.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.