613056 - infinite (or very long) loop in ProcessRestyledFrames while painting

Status: NEW

(Core :: Layout, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: stack

I just hit this, though I have no idea on which page.. browser hung, and WinDbg gave me the attached stack trace.  Stepping out, I get all the way back up to ProcessRestyledFrames, and I can't step out beyond that -- it kept looping with much the same stack every time I broke in.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This was in the 20101116 nightly.  Args in stack trace may be suspect since it's an opt build.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> I just hit this, though I have no idea on which page

If you still have this up, can you look up the URI of the pres shell's mDocument?  Something like ((nsStandardURL*)(mDocument.mRawPtr->mDocumentURI.mRawPtr))->mSpec

Comment 3

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

I'm reluctant to block without steps to reproduce

Comment 4

[Stefan Ring]

I can currently reproduce it reliably. I'm running Fedora 14 x86_64 without hardware graphics acceleration (nouveau.noaccel=1) and Firefox 24 built from source. When browsing a large-ish changeset on bitbucket   https://bitbucket.org/faderAvader/cacao-staging/commits/45f5a8308c8c224ce2a2c4be5580aed5d5e43918   in this case, I only need to move the mouse around a bit and use the scrollbar to scroll up and down across the entire document range, making sure to release and re-grab the scrollbar handle a few times. After doing this a few times, sometimes almost immediately, Firefox becomes unresponsive for many minutes with a stack trace like this:

(gdb) bt
#0  0x00007f4aeb7794b8 in nsLayoutUtils::DoCompareTreePosition(nsIFrame*, nsIFrame*, int, int, nsIFrame*)
    () from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#1  0x00007f4aeb738ded in nsFrameConstructorState::ProcessFrameInsertions (this=0x7fff14dc2ba0,
    aFrameItems=..., aChildListID=mozilla::layout::kAbsoluteList)
    at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:1292
#2  0x00007f4aeb73d9b2 in nsFrameConstructorState::~nsFrameConstructorState (this=0x7fff14dc2ba0,
    __in_chrg=<value optimized out>)
    at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:1005
#3  0x00007f4aeb7458ba in nsCSSFrameConstructor::ContentRangeInserted (this=0x7f4ac25e5800, aContainer=
    0x7f4abd4f0480, aStartChild=0x7f4abcd27b30, aEndChild=0x7f4abd4f0780, aFrameState=0x7f4abcac9900,
    aAllowLazyConstruction=false)
    at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:7030
#4  0x00007f4aeb745c7b in nsCSSFrameConstructor::RecreateFramesForContent (this=0x7f4ac25e5800, aContent=
    0x7f4abcd27b30, aAsyncInsert=false)
    at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:9350
#5  0x00007f4aeb747668 in nsCSSFrameConstructor::ProcessRestyledFrames (this=0x7f4ac25e5800, aChangeList=
    ...) at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:8168
#6  0x00007f4aeb747b7c in nsCSSFrameConstructor::RestyleElement (this=0x7f4ac25e5800,
    aElement=<value optimized out>, aPrimaryFrame=0x7f4ad3b334f0, aMinHint=0, aRestyleTracker=...,
    aRestyleDescendants=true) at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:8316
#7  0x00007f4aeb793c30 in mozilla::css::RestyleTracker::ProcessOneRestyle (this=<value optimized out>,
    aElement=<value optimized out>, aRestyleHint=<value optimized out>,
    aChangeHint=<value optimized out>) at /huge/home/sr/build/mozilla/layout/base/RestyleTracker.cpp:124
#8  0x00007f4aeb7941a7 in mozilla::css::RestyleTracker::DoProcessRestyles (this=0x7f4ac25e5900)
    at /huge/home/sr/build/mozilla/layout/base/RestyleTracker.cpp:209
#9  0x00007f4aeb747a11 in nsCSSFrameConstructor::ProcessPendingRestyles (this=0x7f4ac25e5800)
    at /huge/home/sr/build/mozilla/layout/base/nsCSSFrameConstructor.cpp:12054
#10 0x00007f4aeb79022f in PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#11 0x00007f4aeb781b4a in PresShell::FlushPendingNotifications (this=<value optimized out>,
    aType=<value optimized out>) at /huge/home/sr/build/mozilla/layout/base/nsPresShell.cpp:3737
#12 0x00007f4aeb9a85e2 in nsEventStateManager::PreHandleEvent (this=0x7f4abf603250, aPresContext=
    0x7f4abd0e8c00, aEvent=0x7fff14dc46f0, aTargetFrame=0x7f4ac828d6b0, aStatus=0x7fff14dc452c)
    at /huge/home/sr/build/mozilla/content/events/src/nsEventStateManager.cpp:1016
#13 0x00007f4aeb78d786 in PresShell::HandleEventInternal(nsEvent*, nsEventStatus*) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#14 0x00007f4aeb78db61 in PresShell::HandlePositionedEvent(nsIFrame*, nsGUIEvent*, nsEventStatus*) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#15 0x00007f4aeb78ea61 in PresShell::HandleEvent(nsIFrame*, nsGUIEvent*, bool, nsEventStatus*) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#16 0x00007f4aebaf9bcb in nsViewManager::DispatchEvent(nsGUIEvent*, nsView*, nsEventStatus*) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#17 0x00007f4aebaf83f1 in nsView::HandleEvent(nsGUIEvent*, bool) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#18 0x00007f4aebf687ef in nsWindow::DispatchEvent (this=<value optimized out>,
    aEvent=<value optimized out>, aStatus=@0x7fff14dc479c)
    at /huge/home/sr/build/mozilla/widget/gtk2/nsWindow.cpp:478
#19 0x00007f4aebf6c173 in nsWindow::OnMotionNotifyEvent(_GdkEventMotion*) ()
   from /huge/home/sr/build/mozilla/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so

The starting value for the loop variable (index) in ProcessRestyledFrames is usually around 2200. The stack trace is actually exactly the same almost every time I hit Ctrl-C to interrupt the process in a random location.

Ok, actually this stack trace looks different than the one originally posted here. I don't know if the underlying problem is the same. The code may have changed significantly in the past 3 years.

Comment 5

[Stefan Ring]

Happens all the same on OS X with a downloaded release binary, so the hardware / OS info in my previous comment seems to be insubstantial.

Comment 6

[Stefan Ring]

Oops, my stack trace was from Firefox 23 actually. The symptoms are exactly the same with 24, though.