19494 - CRASH on page with missing glyphs, form, floats...

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Hixie (not reading bugmail)]

This page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/glyphs.html
...crashes Viewer and Mozilla on Windows 98 with the 1999111909 build.

I haven't yet narrowed this down. I'll try to do it tomorrow.

This is the "worst case scenario" test page used for bug 6585.

Comment 1

[troy]

Something whacky in the block code and its handling of floaters

nsBlockBandData::ComputeAvailSpaceRect() line 151 + 18 bytes
nsBlockBandData::ClearFloaters(int 6393, unsigned char 3) line 253
nsBlockReflowState::ClearFloaters(int 6393, unsigned char 3) line 5306 + 28
bytes
nsBlockReflowState::ClearPastFloaters(unsigned char 3) line 829
nsBlockReflowState::RecoverStateFrom(nsLineBox * 0x0261c750, int 1, int 0,
nsRect * 0x0012e6d0) line 942 + 17 bytes
nsBlockFrame::RecoverStateFrom(nsBlockReflowState & {...}, nsLineBox *
0x0261c750, int 0, nsRect * 0x0012e6d0) line 2287
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2462
nsBlockFrame::Reflow(nsBlockFrame * const 0x024fd4e0, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 1490 + 15 bytes
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x024fd4e0, const nsRect & {...},
int 1, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 259 + 45 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox *
0x024fd608, int * 0x0012efc0) line 3256 + 59 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x024fd608, int
* 0x0012efc0, int 1) line 2622 + 20 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2433 + 27 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x024fc3d8, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 1490 + 15 bytes
nsAreaFrame::Reflow(nsAreaFrame * const 0x024fc3d8, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 289 + 25 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x024fc3d8, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0,
unsigned int 0, unsigned int & 0) line 637 + 31 bytes
RootFrame::Reflow(RootFrame * const 0x02533fc8, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 334
nsContainerFrame::ReflowChild(nsIFrame * 0x02533fc8, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0,
unsigned int 1, unsigned int & 0) line 637 + 31 bytes
nsScrollFrame::Reflow(nsScrollFrame * const 0x0256e9a0, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 624
nsContainerFrame::ReflowChild(nsIFrame * 0x0256e9a0, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0,
unsigned int 0, unsigned int & 0) line 637 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x02533ee0, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 527
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x02600a80,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsSize & {...},
nsIRenderingContext & {...}) line 145
PresShell::ProcessReflowCommands(PresShell * const 0x025a4958) line 1650
PresShell::ExitReflowLock(PresShell * const 0x025a4958, int 1, int 1) line 709
PresShell::ContentAppended(PresShell * const 0x025a4960, nsIDocument *
0x01f0ec20, nsIContent * 0x0256119c, int 16) line 2100
nsDocument::ContentAppended(nsDocument * const 0x01f0ec20, nsIContent *
0x0256119c, int 16) line 1515
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x01f0ec20, nsIContent *
0x0256119c, int 16) line 1041

Comment 2

[Sean Richardson]

The testcase for bug 17567 is also reproducibly crashing the browser before
it displays. The latest comment on bug 6585 seem apropos here... if the
"We need to write some more code" is in the midst of being addressed...

The same sort of crashing/hanging problem has come and gone more than once for
testcases for different sections of the HTML 4 Character entities DTDs
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2617 (working now).
At the time that bug 17958 was filed, ⟩ and ⟨ were the only culprits
causing crashes there, and the ISO 8859-1 characters caused a hang, but a week
earlier they weren't, and several other entities in other sections were.

I wish I knew of something better than binary search for this...

Comment 3

[Hixie (not reading bugmail)]

No glyphs required to crash viewer -- here is a simplified test case:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/clear-crash.html
The SELECT element, a long line of floaters and 'clear' all seem to be required
to cause the crash. During simplification, some of the tests just hung instead
of crashing, but I could not see a particular pattern.

Comment 4

[leger]

Updating to default Layout Assignee...kipp no longer with us :-(

Comment 5

[troy]

Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.

Comment 6

[buster]

mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.

Comment 7

[buster]

crashes moved up to M14

Comment 8

[buster]

the problem was nsBlockBandData::ClearFloaters() bypassed the code that manages
the mTrapezoids data structure relative to mCount and mSize.  I fixed this by
factoring out the management code into nsBlockBandData::GetBandData(), calling
GetBandData() from ClearFloaters(), adding a bunch of assertions to catch this
condition should it ever arise again, and adding a comment that nsBlockBandData
should never call mSpaceManager->GetBandData() directly, only through
nsBlockBandData::GetBandData().

Comment 9

[buster]

Attachment: patch

Comment 10

[buster]

if some other object (the space mgr) computed mCount to be more than twice the
size of the current count, we immediately bump up the size to that count.  If
more are needed later, the next call will give us twice this number anyway.

Comment 11

[Chris Petersen]

With the latest build (200010308), the crash is not occuring when loading this
url.