336899 - fuzzing 123greetings crashes or hangs on bad widget tree [@ DoDeletingFrameSubtree] [@ nsIWidget::SetNextSibling]

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Bob Clary [:bc] (inactive)]

Using a saved version of 123greetings.com and fuzzing with randomstyles parameters (195, 40, 24, 178) crashed a linux 20060505 build with stack (TB18362816)

DoDeletingFrameSubtree()
DoDeletingFrameSubtree()
DoDeletingFrameSubtree()
DoDeletingFrameSubtree()
DoDeletingFrameSubtree()
DeletingFrameSubtree()
nsCSSFrameConstructor::ContentRemoved()
nsCSSFrameConstructor::RecreateFramesForContent()
nsCSSFrameConstructor::ProcessRestyledFrames()
nsCSSFrameConstructor::RestyleElement()
nsCSSFrameConstructor::ProcessOneRestyle()
nsCSSFrameConstructor::ProcessPendingRestyles()
nsCSSFrameConstructor::RestyleEvent::HandleEvent()
HandleRestyleEvent()

In a Windows build, it hung after the counter reached ~16000 with ASSERTION: Bogus state: '!mLastChild->GetNextSibling()', ...
mozilla/widget/src/xpwidgets/nsBaseWidget.cpp, line 293

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: test page

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: stdout|stderr log (gzipped)

Summary:

991 ###!!! ASSERTION: Computed overflow area must contain frame bounds: 'aNewSize.width == 0 || aNewSize.height == 0 || aOverflowArea->Contains(nsRect(nsPoint(0, 0), aNewSize))', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/generic/nsFrame.cpp, line 4586
430 ###!!! ASSERTION: Negative Height Input - very bad: 'mComputedHeight >= 0', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/generic/nsHTMLReflowState.cpp, line 2544
234 ###!!! ASSERTION: intial reflow not called: 'HadInitialReflow()', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/tables/nsTableFrame.cpp, line 2003
 33 ###!!! ASSERTION: invalid divisor: 'Error', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/tables/nsTableFrame.cpp, line 3569
 21 ###!!! ASSERTION: Wrapping frame should be block-level: 'aLastRS->frame->GetStyleDisplay()->IsBlockLevel()', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/generic/nsBlockFrame.cpp, line 613
  5 ###!!! ASSERTION: non-root frame's desired size changed during an incremental reflow: 'first == root || (aDesiredSize.width == size.width && aDesiredSize.height == size.height)', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/base/nsPresShell.cpp, line 859
  3 ###!!! ASSERTION: intial reflow not called: 'HadInitialReflow()', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/tables/nsTableFrame.cpp, line 1996
  1 ###!!! ASSERTION: invalid call: 'PR_FALSE', file c:/work/mozilla/builds/ff/trunk/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 1330
  1 ###!!! ASSERTION: Bogus state: '!mLastChild->GetNextSibling()', file c:/work/mozilla/builds/ff/trunk/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp, line 293

504 WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file c:\work\mozilla\builds\ff\trunk\mozilla\obj-dbg\dist\include\layout\nsPresContext.h, line 836
426 WARNING: table initial reflow called twice: file c:/work/mozilla/builds/ff/trunk/mozilla/layout/tables/nsTableFrame.cpp, line 1964
250 WARNING: Couldn't add reflow command, so splitting.
101 WARNING: this reflow doesn't do anything: file c:/work/mozilla/builds/ff/trunk/mozilla/layout/tables/nsTableFrame.cpp, line 2007
 65 WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file c:/work/mozilla/builds/ff/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 8318
 49 WARNING: blowing an incremental reflow targeted at a nested inline: file c:/work/mozilla/builds/ff/trunk/mozilla/layout/generic/nsBlockFrame.cpp, line 1690
 13 WARNING: Strange content ... we can't find logically consistent scrollbar settings: file c:/work/mozilla/builds/ff/trunk/mozilla/layout/generic/nsGfxScrollFrame.cpp, line 647
  4 WARNING: getting z level of unregistered window: file c:/work/mozilla/builds/ff/trunk/mozilla/xpfe/appshell/src/nsWindowMediator.cpp, line 635
  2 WARNING: XPCOM objects created/destroyed from static ctor/dtor: 'gActivityTLS != BAD_TLS_INDEX && NS_PTR_TO_INT32(PR_GetThreadPrivate(gActivityTLS)) == 0', file c:/work/mozilla/builds/ff/trunk/mozilla/xpcom/base/nsTraceRefcntImpl.cpp, line 1085
  1 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file c:/work/mozilla/builds/ff/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
  1 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file c:/work/mozilla/builds/ff/trunk/mozilla/chrome/src/nsChromeRegistry.cpp, line 1251

Comment 3

[Jesse Ruderman]

Is the Linux crash reliable?  What does the status bar counter say just before the crash?

Comment 4

[Bob Clary [:bc] (inactive)]

(In reply to comment #3)
> Is the Linux crash reliable?  What does the status bar counter say just before
> the crash?
> 

No, I have run it with a recent debug build and with today's nightly and it hasn't crashed under linux with reasonable counter values. However I see the DoDeletingFrameSubtree signature in 8 stacks of the 29 stacks I have found so far in this run. I'll send you the link out of band. My _guess_, is that there is a bad pointer like that found in the windows run 
###!!! ASSERTION: Bogus state:  !mLastChild->GetNextSibling()', file
c:/work/mozilla/builds/ff/trunk/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp,
line 293
that is causing the crash point to vary depending cosmic rays or Schrödinger's cat or something.

The hang under Windows with this assert is reproducible.

Comment 5

[Jesse Ruderman]

Filed bug 337268 for the "invalid call" assertion.

I will try to reproduce the "Bogus state" assertion and/or the hang on Windows soon.  If that doesn't lead to a reduced testcase for a crash, I'll also try it under Valgrind on Linux.

Comment 6

[Jesse Ruderman]

Attachment: partially reduced testcase (randomstyles+123greetings, "bogus state" assertion)

Must be loaded locally, not from Bugzilla.

Comment 7

[Jesse Ruderman]

The "Bogus state" assertion also showed up in:
* bug 322704 (has testcase)
* bug 330480 (does not have testcase)
* bug 289032 (WFM)

My partially-reduced testcase shares some features in common with bug 322704 (use of -moz-deck and -moz-popup), so I'm going to guess a fix for bug 322704 will fix it.

I don't get a hang (like bc described for this bug) or a crash (like I get in bug 322704).  Instead, I get into a state like in bug 330998, where toolbar buttons don't respond until you mouse down and move the cursor a pixel, and everything seems a little slow.

Comment 8

[Jesse Ruderman]

Attachment: stack trace for "bogus state" assertion (MSVC 7)

Comment 9

[Jesse Ruderman]

Attachment: stack trace for "reflowing in the middle of frame construction" assertion

While Firefox is in that already-screwed-up state, opening a new tab by middle-clicking the Home button causes:

###!!! ASSERTION: reflowing in the middle of frame construction: 'mPresContext->
mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file c:\buildmoz\mozilla\fb-debug\
dist\include\layout\nsPresContext.h, line 825

Comment 10

[Jesse Ruderman]

My "partially reduced testcase" only causes problems in a debug build, not in an nightly build.

Comment 11

[Jesse Ruderman]

Comment on attachment 221551 [details]
partially reduced testcase (randomstyles+123greetings, "bogus state" assertion)

Can't reproduce any more with this testcase, or with the recorded randomstyles page from which I made this testcase.  Argh!

Comment 12

[Jesse Ruderman]

Comment on attachment 221551 [details]
partially reduced testcase (randomstyles+123greetings, "bogus state" assertion)

Oops.  I can still reproduce on Windows, just not on Mac.

Comment 13

[Jesse Ruderman]

But now I get a crash instead of a semi-hang.  Stack trace to follow.

Comment 14

[Jesse Ruderman]

Attachment: Stack trace for the crash [@ nsIWidget::SetNextSibling] attempting to read memory at 0xDADADADA.

Comment 15

[Jesse Ruderman]

WFM on Windows now.  (Saved the "partially reduced testcase" and tested with a debug build.)

Comment 16

[Martijn Wargers (dead)]

This is also wfm, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061114 Minefield/3.0a1
Can this bug be marked worksforme?

Comment 17

[Jesse Ruderman]

Marking WFM.  I'm still testing (updated versions of) this fuzzer on a wide variety of pages, so I'm not worried about missing anything as a result of marking this bug as WFM.