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

VERIFIED FIXED in M14

Status

()

P1
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: ian, Assigned: buster)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in hand, URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Blocks: 6585
Whiteboard: (py8ieh:will narrow down)

Updated

19 years ago
Assignee: troy → kipp

Comment 1

19 years ago
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

19 years ago
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...
(Reporter)

Comment 3

19 years ago
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

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

Comment 5

19 years ago
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.
(Assignee)

Comment 6

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M15 → M14
(Assignee)

Comment 7

19 years ago
crashes moved up to M14
(Assignee)

Updated

19 years ago
Priority: P3 → P1
(Assignee)

Updated

19 years ago
Assignee: kipp → buster
Whiteboard: (py8ieh:will narrow down) → fix in hand
(Assignee)

Comment 8

19 years ago
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().
(Assignee)

Comment 9

19 years ago
Created attachment 3742 [details] [diff] [review]
patch
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 11

19 years ago
With the latest build (200010308), the crash is not occuring when loading this
url.
You need to log in before you can comment on or make changes to this bug.