974905 - Assertion failure: "SchedulePaint in a detached pres context" reproducible by running reftest-sanity with e10s prefs

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

STR:
 1. Apply the above patch setting e10s preferences
 2. Make a Linux debug build
 3. ./mach reftest layout/reftests/reftest-sanity/

Result:

A content process crashes with:

Program received signal SIGSEGV, Segmentation fault.
nsIFrame::SchedulePaint (this=0x2b4df560e458, aType=nsIFrame::PAINT_DEFAULT) at /hack/mozilla-central/layout/generic/nsFrame.cpp:4892
4892      MOZ_ASSERT(pres->GetContainerWeak(), "SchedulePaint in a detached pres context");
(gdb) bt
#0  nsIFrame::SchedulePaint (this=0x2b4df560e458, aType=nsIFrame::PAINT_DEFAULT) at /hack/mozilla-central/layout/generic/nsFrame.cpp:4892
#1  0x00002b4de1a2a3a8 in InvalidateFrameInternal (aFrame=0x2b4df560e458, aHasDisplayItem=true)
    at /hack/mozilla-central/layout/generic/nsFrame.cpp:4727
#2  0x00002b4de1a2a241 in nsIFrame::InvalidateFrame (this=0x2b4df560e458, aDisplayItemKey=0) at /hack/mozilla-central/layout/generic/nsFrame.cpp:4786
#3  0x00002b4de1a29f6c in nsIFrame::InvalidateFrameSubtree (this=0x2b4df560e458, aDisplayItemKey=0)
    at /hack/mozilla-central/layout/generic/nsFrame.cpp:4740
#4  0x00002b4de199c39c in nsPresContext::InvalidateThebesLayers (this=0x2b4df4b1c800) at /hack/mozilla-central/layout/base/nsPresContext.cpp:872
#5  0x00002b4de199963d in nsPresContext::UpdateAfterPreferencesChanged (this=0x2b4df4b1c800) at /hack/mozilla-central/layout/base/nsPresContext.cpp:976
#6  0x00002b4de1999527 in nsPresContext::PrefChangedUpdateTimerCallback (aTimer=0x2b4df49aa700, aClosure=0x2b4df4b1c800)
    at /hack/mozilla-central/layout/base/nsPresContext.cpp:228
#7  0x00002b4ddee906b5 in nsTimerImpl::Fire (this=0x2b4df49aa700) at /hack/mozilla-central/xpcom/threads/nsTimerImpl.cpp:551
#8  0x00002b4ddee90a81 in nsTimerEvent::Run (this=0x2b4df3442830) at /hack/mozilla-central/xpcom/threads/nsTimerImpl.cpp:635
#9  0x00002b4ddee8b989 in nsThread::ProcessNextEvent (this=0x2b4dee06d480, mayWait=false, result=0x7fff6708db7e)
    at /hack/mozilla-central/xpcom/threads/nsThread.cpp:643
#10 0x00002b4dded8ee48 in NS_ProcessNextEvent (thread=0x2b4dee06d480, mayWait=false) at /hack/mozilla-central/xpcom/glue/nsThreadUtils.cpp:263
#11 0x00002b4ddf423b33 in mozilla::ipc::MessagePump::Run (this=0x2b4dee013480, aDelegate=0x7fff6708df98)
    at /hack/mozilla-central/ipc/glue/MessagePump.cpp:95
#12 0x00002b4ddf4248e3 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x2b4dee013480, aDelegate=0x7fff6708df98)
    at /hack/mozilla-central/ipc/glue/MessagePump.cpp:283
#13 0x00002b4ddf3b1496 in MessageLoop::RunInternal (this=0x7fff6708df98) at /hack/mozilla-central/ipc/chromium/src/base/message_loop.cc:226
#14 0x00002b4ddf3b13c5 in MessageLoop::RunHandler (this=0x7fff6708df98) at /hack/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#15 0x00002b4ddf3b139d in MessageLoop::Run (this=0x7fff6708df98) at /hack/mozilla-central/ipc/chromium/src/base/message_loop.cc:193
#16 0x00002b4de0769541 in nsBaseAppShell::Run (this=0x2b4df0a91eb0) at /hack/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:164
#17 0x00002b4de221a601 in XRE_RunAppShell () at /hack/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:679
#18 0x00002b4ddf424704 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x2b4dee013480, aDelegate=0x7fff6708df98)
    at /hack/mozilla-central/ipc/glue/MessagePump.cpp:253
#19 0x00002b4ddf3b1496 in MessageLoop::RunInternal (this=0x7fff6708df98) at /hack/mozilla-central/ipc/chromium/src/base/message_loop.cc:226
#20 0x00002b4ddf3b13c5 in MessageLoop::RunHandler (this=0x7fff6708df98) at /hack/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#21 0x00002b4ddf3b139d in MessageLoop::Run (this=0x7fff6708df98) at /hack/mozilla-central/ipc/chromium/src/base/message_loop.cc:193
#22 0x00002b4de2219f6e in XRE_InitChildProcess (aArgc=3, aArgv=0x7fff6708f528, aProcess=GeckoProcessType_Content)
    at /hack/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:516
#23 0x0000000000403586 in main (argc=5, argv=0x7fff6708f528) at /hack/mozilla-central/ipc/app/MozillaRuntimeMain.cpp:149


(gdb) l
4887      // painted directly.
4888      if (!pres || (pres->Document() && pres->Document()->IsResourceDoc())) {
4889        return;
4890      }
4891      
4892      MOZ_ASSERT(pres->GetContainerWeak(), "SchedulePaint in a detached pres context");
4893      pres->PresShell()->ScheduleViewManagerFlush(aType == PAINT_DELAYED_COMPRESS ?
4894                                                  nsIPresShell::PAINT_DELAYED_COMPRESS :
4895                                                  nsIPresShell::PAINT_DEFAULT);
4896

(gdb) p pres->mContainer
$4 = {
  <mozilla::WeakPtrBase<nsDocShell, mozilla::detail::WeakReference<nsDocShell> >> = {
    ref = {
      ptr = 0x2b4df5a18b70
    }
  }, <No data fields>}
(gdb) p pres->mContainer.ref
$5 = {
  ptr = 0x2b4df5a18b70
}
(gdb) p pres->mContainer.ref.ptr
$6 = (mozilla::detail::WeakReference<nsDocShell> *) 0x2b4df5a18b70
(gdb) p *(pres->mContainer.ref.ptr)
$7 = {
  <mozilla::RefCounted<mozilla::detail::WeakReference<nsDocShell> >> = {
    <mozilla::detail::RefCounted<mozilla::detail::WeakReference<nsDocShell>, 1>> = {
      refCnt = 1
    }, <No data fields>}, 
  members of mozilla::detail::WeakReference<nsDocShell>: 
  ptr = 0x0
}

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Patch setting IPC preferences

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

Possibly related: bug 967758.

Comment 3

[Mats Palmgren (:mats)]

Attachment: stack

Comment 4

[Mats Palmgren (:mats)]

So we still observe pref changes in a Detached pres context with a Frozen shell...
Hmm, I don't think we should try to do layout stuff in that state so perhaps
we should just blow away the frame tree in UpdateAfterPreferencesChanged in 
that state?  (assuming we'll recreate it when we're unfrozen, should that happen)
Or do we have some other mechanism to delay this update?

Comment 5

[Mats Palmgren (:mats)]

Attachment: Warn and ignore SchedulePaint calls in a detached pres context.

I still think the assertion is correct but I don't have time to hunt this
down right now so let's just warn and return early for now.  I think it
should be rare in normal use.

Comment 6

[Mats Palmgren (:mats)]

https://tbpl.mozilla.org/?tree=Try&rev=7ee6dfd65fef

Comment 7

[Mats Palmgren (:mats)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c2f752b69b3a

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c2f752b69b3a