Closed
Bug 974905
Opened 9 years ago
Closed 9 years ago
Assertion failure: "SchedulePaint in a detached pres context" reproducible by running reftest-sanity with e10s prefs
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: bjacob, Assigned: MatsPalmgren_bugz)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
1.23 KB,
patch
|
Details | Diff | Splinter Review | |
9.70 KB,
text/plain
|
Details | |
1.24 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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 }
Reporter | ||
Comment 1•9 years ago
|
||
Reporter | ||
Comment 2•9 years ago
|
||
Possibly related: bug 967758.
Assignee | ||
Comment 3•9 years ago
|
||
Assignee: nobody → matspal
Assignee | ||
Comment 4•9 years ago
|
||
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?
Assignee | ||
Comment 5•9 years ago
|
||
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.
Attachment #8379483 -
Flags: review?(roc)
Assignee | ||
Comment 6•9 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=7ee6dfd65fef
Attachment #8379483 -
Flags: review?(roc) → review+
Assignee | ||
Comment 7•9 years ago
|
||
landing |
https://hg.mozilla.org/integration/mozilla-inbound/rev/c2f752b69b3a
Comment 8•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c2f752b69b3a
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in
before you can comment on or make changes to this bug.
Description
•