31137 - layout uses too much stack space

Status: VERIFIED DUPLICATE of bug 32201

(Core :: Layout, defect, P3)

Description

[Jason Eager]

The above url (WARNING: Explicit links present on that page)
consistantly crashes Nightly builds 2000030809 and 2000030507.
the M14 build does NOT crash, but it acts strangely with long
delays on that page.

The page is rather austere..it is just a links page, I don't see
what is crashing it. No javascript, no java. Just HTML.

Comment 1

[Simon Fraser [no longer active]]

Attachment: Stack crawl for the crash

Comment 2

[Simon Fraser [no longer active]]

I attached a stack crawl, that looks like infinite recursion thus:

...  0E099320    PPC  1C7E3CA8  nsInlineFrame::Reflow(nsIPresContext*, 
nsHTMLReflowMetrics&, const nsHTMLReflowState&, unsigned int&)+E3CA8
  0E0992B0    PPC  1C7E4110  nsInlineFrame::ReflowFrames(nsIPresContext*, const 
nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, 
unsigned int&)+E4110
  0E099200    PPC  1C7E4760  nsInlineFrame::ReflowInlineFrame(nsIPresContext*, 
const nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned 
int&)+E4760
  0E099180    PPC  1C7F9D64  nsLineLayout::ReflowFrame(nsIFrame*, nsIFrame**, 
unsigned int&, nsHTMLReflowMetrics*, int&)+F9D64
  0E098DC0    PPC  1C7E3CA8  nsInlineFrame::Reflow(nsIPresContext*, 
nsHTMLReflowMetrics&, const nsHTMLReflowState&, unsigned int&)+E3CA8
  0E098D50    PPC  1C7E4110  nsInlineFrame::ReflowFrames(nsIPresContext*, const 
nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, 
unsigned int&)+E4110
  0E098CA0    PPC  1C7E4760  nsInlineFrame::ReflowInlineFrame(nsIPresContext*, 
const nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned 
int&)+E4760
  0E098C20    PPC  1C7F9D64  nsLineLayout::ReflowFrame(nsIFrame*, nsIFrame**, 
unsigned int&, nsHTMLReflowMetrics*, int&)+F9D64
  0E098860    PPC  1C7E3CA8  nsInlineFrame::Reflow(nsIPresContext*, 
nsHTMLReflowMetrics&, const nsHTMLReflowState&, unsigned int&)+E3CA8
  0E0987F0    PPC  1C7E4110  nsInlineFrame::ReflowFrames(nsIPresContext*, const 
nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, 
unsigned int&)+E4110
  0E098740    PPC  1C7E4760  nsInlineFrame::ReflowInlineFrame(nsIPresContext*, 
const nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned 
int&)+E4760
  0E0986C0    PPC  1C7F9D64  nsLineLayout::ReflowFrame(nsIFrame*, nsIFrame**, 
unsigned int&, nsHTMLReflowMetrics*, int&)+F9D64
  0E098300    PPC  1C7E3CA8  nsInlineFrame::Reflow(nsIPresContext*, 
nsHTMLReflowMetrics&, const nsHTMLReflowState&, unsigned int&)+E3CA8
  0E098290    PPC  1C7E4110  nsInlineFrame::ReflowFrames(nsIPresContext*, const 
nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, 
unsigned int&)+E4110
  0E0981E0    PPC  1C7E4760  nsInlineFrame::ReflowInlineFrame(nsIPresContext*, 
const nsHTMLReflowState&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned 
int&)+E4760
  0E098160    PPC  1C7F9D64  nsLineLayout::ReflowFrame(nsIFrame*, nsIFrame**, 
unsigned int&, 
...

Comment 3

[Simon Fraser [no longer active]]

Note: this page seems to have a lot of unclosed tags, like <font> tags.

Comment 4

[buster]

assigned to rickg.  if you look at the content model, we seem to be getting 
incredibly deep nestings on font tags as we go deeper into the document.  since 
Nav4 handles this page just fine, maybe we need a quirks-mode setting to handle 
the unclosed font tags?

Comment 5

[rickg]

Buster: the fact that the page is filled with lousy html means I have to do a 
lot of cleanup. After beta, I'll be improving RS handling to NOT do any 
processing if the RS tags are will formed (if misplaced). The crash is due to 
the excessively huge stack space required by linelayout, so I'm giving this back 
to you.

Comment 6

[buster]

the problem here is the stack space being used for very deep documents.  Rick 
will make is so fewer documents unintentionally produce deep content trees, but 
there is still a problem with core layout and stack usage.  This bug is now a 
placeholder for that problem.

Comment 7

[troy]

Steve, Eric Vaughan is working on a new API that will allow us to allow layout 
memory in a stack-like manner but have it come out of the heap (memory arenas 
actually, so the overhead cost is low).

When that's available, all of Kipp's stack based data structures should be 
allocated that way.

I will change the HTML reflow state data itself to be allocated that way as 
well

That should reduce the amount of actual stack space per Reflow() invocation down 
to something reasonable

My goal has always been to have a frame allocate no more than 100 bytes of stack 
space during its reflow. Ideally it would be even less, but at 100 bytes we can 
support a very nested tree. Even with only a 100K stack we would be in the 
ballpark of supporting a tree with a height of 1000.

Comment 8

[Jason Eager]

I can now isolate the crash on this page to the unclosed <FONT> tags. I went

through the HTML and closed all the tags, and that version of the page does

NOT crash Mozilla, while the original version still does.



I'm asking her (via e-mail) if I can attach a copy of the bad HTML page to

this bug, and then if she would replace the current links page with my

fixed page.

Comment 9

[Dawn Endico]

take a look at bug 32201. It looks like a dup of this bug. If so, then this
bug should probably be raised to the status of beta blocker because wired.com
just changed their layout so it uses lots of unclosed font tags and crashes 
linux builds. M14 was broken so i imagine the beta branch is too although i 
haven't tested it

Comment 10

[troy]

It's too late for a beta blocker, and this problem is too involved to be fixed 
at this late stage of the game anyway

Comment 11

[Antti Näyhä]

The test case URL doesn't crash build 2000-04-24-09 (Red Hat 6.2, kernel
2.2.14).  That probably makes this one a dup of bug 32201, since that one has
been fixed in the meantime.

Marking Resolved/Duplicate - I hope it doesn't matter that this one is actually
older than bug 32201?

*** This bug has been marked as a duplicate of 32201 ***

Comment 12

[Matt Perry]

Verified duplicate.