If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

layout uses too much stack space

VERIFIED DUPLICATE of bug 32201

Status

()

Core
Layout
P3
critical
VERIFIED DUPLICATE of bug 32201
18 years ago
17 years ago

People

(Reporter: Jason Eager, Assigned: buster)

Tracking

({perf})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

18 years ago
Created attachment 6339 [details]
Stack crawl for the crash

Comment 2

18 years ago
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&, 
...
Assignee: cbegle → troy
Component: Browser-General → Layout
Summary: [CRASHER][REGRESSION] A certain web page consistantly crashes Mozilla. → [CRASHER][REGRESSION] Web page crashes -- infinite recursion in Reflow

Comment 3

18 years ago
Note: this page seems to have a lot of unclosed tags, like <font> tags.
(Assignee)

Comment 4

18 years ago
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?
Assignee: troy → rickg

Comment 5

18 years ago
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.
Assignee: rickg → buster
(Assignee)

Comment 6

18 years ago
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.
Status: NEW → ASSIGNED
Keywords: perf
Summary: [CRASHER][REGRESSION] Web page crashes -- infinite recursion in Reflow → layout uses too much stack space
Target Milestone: M18

Comment 7

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

Comment 8

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

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

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

18 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 12

17 years ago
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.