845337 - layout/base/nsPresShell.cpp:5428 MOZ_ASSERT(presContext->IsRootContentDocument() failure

Reporter

Description

•

12 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.84 Safari/537.22 Steps to reproduce: Firefox crashes if I open an article on http://www.sueddeutsche.de/ and press the back button. Here is a backtrace: ... Assertion failure: presContext->IsRootContentDocument() (Didn't get a root prescontext from GetToplevelContentDocumentPresContext?), at /home/markus/mozilla-central/layout/base/nsPresShell.cpp:5429 Program received signal SIGSEGV, Segmentation fault. PresShell::ScheduleImageVisibilityUpdate (this=<optimized out>) at /home/markus/mozilla-central/layout/base/nsPresShell.cpp:5428 5428 MOZ_ASSERT(presContext->IsRootContentDocument(), (gdb) bt #0 PresShell::ScheduleImageVisibilityUpdate (this=<optimized out>) at /home/markus/mozilla-central/layout/base/nsPresShell.cpp:5428 #1 0x00007ffff46531c4 in ThawSubDocument (aDocument=<optimized out>, aData=<optimized out>) at /home/markus/mozilla-central/layout/base/nsPresShell.cpp:7547 #2 0x00007ffff4876750 in SubDocHashEnum (table=table@entry=0x7fffc5d7cbe0, hdr=hdr@entry=0x7fffcbc973e8, number=number@entry=0, arg=arg@entry=0x7fffffffcb90) at /home/markus/mozilla-central/content/base/src/nsDocument.cpp:7268 #3 0x00007ffff553664b in PL_DHashTableEnumerate (table=0x7fffc5d7cbe0, etor=0x7ffff487673d <SubDocHashEnum(PLDHashTable*, PLDHashEntryHdr*, uint32_t, void*)>, arg=0x7fffffffcb90) at /var/tmp/moz-build-dir/xpcom/build/pldhash.cpp:717 #4 0x00007ffff48782dc in nsDocument::EnumerateSubDocuments (this=<optimized out>, aCallback=<optimized out>, aData=<optimized out>) at /home/markus/mozilla-central/content/base/src/nsDocument.cpp:7278 #5 0x00007ffff4657c5e in PresShell::Thaw (this=0x7fffc34cae00) at /home/markus/mozilla-central/layout/base/nsPresShell.cpp:7564 #6 0x00007ffff4f71d23 in nsDocShell::RestoreFromHistory (this=0x7fffc3003c00) at /home/markus/mozilla-central/docshell/base/nsDocShell.cpp:7848 #7 0x00007ffff4f71e56 in nsDocShell::RestorePresentationEvent::Run (this=<optimized out>) at /home/markus/mozilla-central/docshell/base/nsDocShell.cpp:7225 #8 0x00007ffff55784b0 in nsThread::ProcessNextEvent (this=0x7ffff7166c80, mayWait=<optimized out>, result=<optimized out>) at /home/markus/mozilla-central/xpcom/threads/nsThread.cpp:627 #9 0x00007ffff5535126 in NS_ProcessNextEvent_P (thread=<optimized out>, mayWait=<optimized out>) at /var/tmp/moz-build-dir/xpcom/build/nsThreadUtils.cpp:238 #10 0x00007ffff5247153 in mozilla::ipc::MessagePump::Run (this=0x7ffff71d9700, aDelegate=0x7fffefc020b0) at /home/markus/mozilla-central/ipc/glue/MessagePump.cpp:117 #11 0x00007ffff55a785a in MessageLoop::RunInternal (this=this@entry=0x7fffefc020b0) at /home/markus/mozilla-central/ipc/chromium/src/base/message_loop.cc:216 #12 0x00007ffff55a7882 in RunHandler (this=0x7fffefc020b0) at /home/markus/mozilla-central/ipc/chromium/src/base/message_loop.cc:209 #13 MessageLoop::Run (this=0x7fffefc020b0) at /home/markus/mozilla-central/ipc/chromium/src/base/message_loop.cc:183 #14 0x00007ffff51ac93b in nsBaseAppShell::Run (this=0x7fffee034ef0) at /home/markus/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:163 #15 0x00007ffff500245c in nsAppStartup::Run (this=0x7fffee08f240) at /home/markus/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:288 #16 0x00007ffff440e75f in XREMain::XRE_mainRun (this=this@entry=0x7fffffffd0f8) at /home/markus/mozilla-central/toolkit/xre/nsAppRunner.cpp:3885 #17 0x00007ffff440eba7 in XREMain::XRE_main (this=this@entry=0x7fffffffd0f8, argc=argc@entry=1, argv=argv@entry=0x7fffffffe578, aAppData=aAppData@entry=0x7fffffffd2f0) at /home/markus/mozilla-central/toolkit/xre/nsAppRunner.cpp:3952 #18 0x00007ffff440edd8 in XRE_main (argc=1, argv=0x7fffffffe578, aAppData=0x7fffffffd2f0, aFlags=<optimized out>) at /home/markus/mozilla-central/toolkit/xre/nsAppRunner.cpp:4155 #19 0x00000000004031a7 in do_main (argc=argc@entry=1, argv=argv@entry=0x7fffffffe578, xreDirectory=0x7ffff71316c0) at /home/markus/mozilla-central/browser/app/nsBrowserApp.cpp:224 #20 0x00000000004032f8 in main (argc=1, argv=0x7fffffffe578) at /home/markus/mozilla-central/browser/app/nsBrowserApp.cpp:522

[:Aleksej]

Comment 1

•

12 years ago

No crash here with 2013-02-26-03-10-02-mozilla-central-firefox-22.0a1.ru.linux-x86_64. Can you try with an official nightly build?

Octoploid

Reporter

Comment 2

•

12 years ago

(In reply to Aleksej [:Aleksej] from comment #1) > No crash here with > 2013-02-26-03-10-02-mozilla-central-firefox-22.0a1.ru.linux-x86_64. Can you > try with an official nightly build? Yes. The official nightly build also crashes: Program received signal SIGINT, Interrupt. 0x00007ffff3e2e658 in nsPresContext::IsRootContentDocument() () from /var/tmp/firefox/libxul.so (gdb) bt #0 0x00007ffff3e2e658 in nsPresContext::IsRootContentDocument() () from /var/tmp/firefox/libxul.so #1 0x00007ffff3e398fc in PresShell::ScheduleImageVisibilityUpdate() () from /var/tmp/firefox/libxul.so #2 0x00007ffff31943c7 in ThawSubDocument(nsIDocument*, void*) () from /var/tmp/firefox/libxul.so #3 0x00007ffff3f3e105 in SubDocHashEnum(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*) () from /var/tmp/firefox/libxul.so #4 0x00007ffff43bd55c in PL_DHashTableEnumerate () from /var/tmp/firefox/libxul.so #5 0x00007ffff3f400c1 in nsDocument::EnumerateSubDocuments(bool (*)(nsIDocument*, void*), void*) () from /var/tmp/firefox/libxul.so #6 0x00007ffff31959a8 in PresShell::Thaw() () from /var/tmp/firefox/libxul.so #7 0x00007ffff34e9a41 in nsDocShell::RestoreFromHistory() () from /var/tmp/firefox/libxul.so #8 0x00007ffff34e9cc6 in nsDocShell::RestorePresentationEvent::Run() () from /var/tmp/firefox/libxul.so #9 0x00007ffff43e3aa5 in nsThread::ProcessNextEvent(bool, bool*) () from /var/tmp/firefox/libxul.so #10 0x00007ffff43bbe9c in NS_ProcessNextEvent_P(nsIThread*, bool) () from /var/tmp/firefox/libxul.so #11 0x00007ffff4342335 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /var/tmp/firefox/libxul.so #12 0x00007ffff4406d63 in MessageLoop::Run() () from /var/tmp/firefox/libxul.so #13 0x00007ffff35fb41e in nsBaseAppShell::Run() () from /var/tmp/firefox/libxul.so #14 0x00007ffff3524940 in nsAppStartup::Run() () from /var/tmp/firefox/libxul.so #15 0x00007ffff3070817 in XREMain::XRE_mainRun() () from /var/tmp/firefox/libxul.so #16 0x00007ffff3073a94 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /var/tmp/firefox/libxul.so #17 0x00007ffff3073c27 in XRE_main () from /var/tmp/firefox/libxul.so #18 0x0000000000407820 in do_main(int, char**, nsIFile*) () #19 0x0000000000407aec in main ()

Octoploid

Reporter

Comment 3

•

12 years ago

Probably caused by Bug 689623 or Bug 816498. Adding CC.

[:Aleksej]

Updated

•

12 years ago

Severity: normal → critical

Keywords: crash

Timothy Nikkel (:tnikkel)

Assignee

Updated

•

12 years ago

Blocks: 689623

Timothy Nikkel (:tnikkel)

Assignee

Updated

•

12 years ago

Assignee: nobody → tnikkel

Timothy Nikkel (:tnikkel)

Assignee

Updated

•

12 years ago

Component: Untriaged → Layout

Product: Firefox → Core

Timothy Nikkel (:tnikkel)

Assignee

Comment 4

•

12 years ago

I haven't been able to reproduce yet. Hopefully I can figure it out from the stack.

Octoploid

Reporter

Comment 5

•

12 years ago

(In reply to Timothy Nikkel (:tn) from comment #4) > I haven't been able to reproduce yet. Hopefully I can figure it out from the > stack. To reproduce just go to http://www.sueddeutsche.de/ and click on any article link. Now press the back button and then the forward button immediately.

Octoploid

Reporter

Comment 6

•

12 years ago

Further testing revealed that Firefox only crashes when the NoScript 2.6.5.7 addon is enabled.

Timothy Nikkel (:tnikkel)

Assignee

Comment 7

•

12 years ago

That makes sense that NoScript is required as the lack of scripts means we can use the bfcache for those pages. Unfortunately I've still not reproduced. Can you try a try build for me to see if it still has the problem?

Octoploid

Reporter

Comment 8

•

12 years ago

(In reply to Timothy Nikkel (:tn) from comment #7) > That makes sense that NoScript is required as the lack of scripts means we > can use the bfcache for those pages. > > Unfortunately I've still not reproduced. > > Can you try a try build for me to see if it still has the problem? Sure, just send me a link.

Timothy Nikkel (:tnikkel)

Assignee

Comment 9

•

12 years ago

Great, thank you. The builds will be available in an hour or two at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-aef0dee83e38 I can post again when they are actually available.

Timothy Nikkel (:tnikkel)

Assignee

Comment 10

•

12 years ago

The try builds are now available.

Timothy Nikkel (:tnikkel)

Assignee

Updated

•

12 years ago

Flags: needinfo?(cryptooctoploid)

Octoploid

Reporter

Comment 11

•

12 years ago

The crash isn't reproducible on your try-build.

Flags: needinfo?(cryptooctoploid)

Octoploid

Reporter

Comment 12

•

12 years ago

Applying http://hg.mozilla.org/try/rev/23d3be9bf7c7 on top of my local tree also fixes the issue.

Timothy Nikkel (:tnikkel)

Assignee

Comment 13

•

12 years ago

Attached patch patch — Details — Splinter Review

Looks like we have a prescontext that doesn't have a root frame yet. So we have to fall back to views. We've had this problem before.

Attachment #719019 - Flags: review?(roc)

Scoobidiver (away)

Updated

•

12 years ago

Blocks: 845719

Scoobidiver (away)

Updated

•

12 years ago

Blocks: 845722

Scoobidiver (away)

Updated

•

12 years ago

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

Timothy Nikkel (:tnikkel)

Assignee

Comment 14

•

12 years ago

(In reply to Octoploid from comment #12) > Applying http://hg.mozilla.org/try/rev/23d3be9bf7c7 on top of my local > tree also fixes the issue. Thanks for your help!

Robert O'Callahan (:roc) (email my personal email if necessary)

Updated

•

12 years ago

Attachment #719019 - Flags: review?(roc) → review+

Timothy Nikkel (:tnikkel)

Assignee

Comment 15

•

12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/3d20e0577cbf

Ryan VanderMeulen [:RyanVM]

Comment 16

•

12 years ago

https://hg.mozilla.org/mozilla-central/rev/3d20e0577cbf

Status: ASSIGNED → RESOLVED

Closed: 12 years ago

Resolution: --- → FIXED

Target Milestone: --- → mozilla22

Mats Palmgren (inactive)

Comment 17

•

12 years ago

(In reply to Timothy Nikkel (:tn) from comment #13) > Looks like we have a prescontext that doesn't have a root frame yet. So we > have to fall back to views. We've had this problem before. Did you figure out why that happens? (I'm leaning towards that it's a bug.) I tried reproducing the crash locally in a Linux64 debug build (without the fix) using a clean profile and installing NoScript, but it didn't crash. :-(

Timothy Nikkel (:tnikkel)

Assignee

Comment 18

•

12 years ago

It's a valid state as far as I can tell. We don't create the root frame until PresShell::InitialReflow (now renamed to Initialize) is called. But we create the root view and everything when we create the presentation. I have reproduced the case where we don't have a root frame before (just couldn't reproduce in this bug). As far as I could tell everything was working as designed. We could change that so we always have a root frame though.

Mats Palmgren (inactive)

Comment 19

•

12 years ago

> As far as I could tell everything was working as designed. OK. The "presentation setup" in docshell/documentviewer is hairy so probably not worth messing with for this problem.

Timothy Nikkel (:tnikkel)

Assignee

Comment 20

•

12 years ago

(In reply to Mats Palmgren [:mats] from comment #19) > > As far as I could tell everything was working as designed. > > OK. The "presentation setup" in docshell/documentviewer is hairy so probably > not worth messing with for this problem. No, I don't think we'd want to change that. But we could construct the root frame sooner, that seems less problematic.