Closed Bug 112360 Opened 23 years ago Closed 23 years ago

rapid memory leak parsing page

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: ralph, Assigned: attinasi_layout)

References

(
URL
)

Details

(Keywords: memory-leak)

Attachments

(1 file)

Somewhat reduced testcase -- takes a long time to load
11.01 KB, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 BuildID: 2001112009 Moz 0.9.6, on a fairly freshly installed RH7.2 Linux, and a fairly freshly installed W2K, rapidly leaks instead of displaying the page when I try to access the URL. To my surprise, when I saved the page locally using IE and read it using Moz, it read and displayed it fine. Hmm. Thus I'm filing this as a Networking bug rather than a Browser bug. Reproducible: Always Steps to Reproduce: 1. Load URL. Actual Results: Browser stops responding as a rapid leak marches Moz to oblivion. Expected Results: Display the page and not leak.
I see this behaviour too (sucking 100% cpu, eating c:a 1 MB/s). Build ID: 2001 11 27 03. Windows 2000.
I can confirm this. Build 2001112603 on Win2K
Keywords: mlk
Confirming. WinMe, WinNT
Status: UNCONFIRMED → NEW
Ever confirmed: true
Note: The page that is causing trouble has multiple <TITLE> tags, and they're in the <BODY> section of the html, not the <HEAD>
-> Parser Aside from having 28 <title> elements in the body, it also has 63 <span> but only 35 </span> tags. Working on a testcase.
Assignee: neeti → harishd
QA Contact: benc → moied
Ok, as I have been working on finding a minimal testcase, the page always gets to a point where it does end up eventually loading. I bet on a machine that's fast enough and has enough RAM, the URL for this bug will eventually load. I'll post a testcase which has been reduced a bit and does load, but it takes way too long and uses too much memory. Further reducing caused the page to load up pretty quick.
Component: Networking → Parser
Summary: rapid runaway unstoppable memory leak → rapid memory leak parsing page
*** Bug 112486 has been marked as a duplicate of this bug. ***
All I get is a hang: nsQueryInterface::nsQueryInterface(const nsQueryInterface & {...}) + 52 bytes do_QueryInterface(nsISupports * 0x00b47d60, unsigned int * 0x00000000) line 358 + 27 bytes nsCOMPtr<nsIAtom>::Assert_NoQueryNeeded() line 500 + 17 bytes nsGetterAddRefs<nsIAtom>::~nsGetterAddRefs<nsIAtom>() line 1056 StyleSetImpl::ProbePseudoStyleFor(nsIPresContext * 0x02d605a0, nsIContent * 0x02dca490, nsIAtom * 0x00b211d0, nsIStyleContext * 0x0171cce0, int 0) line 1190 nsPresContext::ProbePseudoStyleContextFor(nsPresContext * const 0x02d605a0, nsIContent * 0x02dca490, nsIAtom * 0x00b211d0, nsIStyleContext * 0x0171cce0, int 0, nsIStyleContext * * 0x00123914) line 1045 + 45 bytes nsCSSFrameConstructor::CreateGeneratedContentFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIFrame * 0x0170792c, nsIContent * 0x02dca490, nsIStyleContext * 0x0171cce0, nsIAtom * 0x00b211d0, int 0, nsIFrame * * 0x00123968) line 1433 + 50 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dca490, nsIFrame * 0x0170792c, int 1, nsFrameItems & {...}, int * 0x00123a84) line 13209 + 59 bytes nsCSSFrameConstructor::ConstructInline(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dca490, nsIFrame * 0x01707bf0, nsIStyleContext * 0x0171cce0, int 0, nsIFrame * 0x0170792c, nsIFrame * * 0x00123e04, nsIFrame * * 0x00123dd4) line 13008 + 38 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dca490, nsIFrame * 0x01707bf0, nsIStyleContext * 0x0171cce0, nsFrameItems & {...}) line 6321 + 53 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dca490, nsIFrame * 0x01707bf0, nsIAtom * 0x00b17030, int 3, nsIStyleContext * 0x0171cce0, nsFrameItems & {...}, int 0) line 7102 + 45 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dca490, nsIFrame * 0x01707bf0, nsFrameItems & {...}) line 6970 + 56 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dca760, nsIFrame * 0x01707bf0, int 1, nsFrameItems & {...}, int * 0x0012406c) line 13224 + 69 bytes nsCSSFrameConstructor::ConstructInline(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dca760, nsIFrame * 0x01707eb4, nsIStyleContext * 0x0171dbcc, int 0, nsIFrame * 0x01707bf0, nsIFrame * * 0x001243ec, nsIFrame * * 0x001243bc) line 13008 + 38 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dca760, nsIFrame * 0x01707eb4, nsIStyleContext * 0x0171dbcc, nsFrameItems & {...}) line 6321 + 53 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dca760, nsIFrame * 0x01707eb4, nsIAtom * 0x00b44cf0, int 3, nsIStyleContext * 0x0171dbcc, nsFrameItems & {...}, int 0) line 7102 + 45 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dca760, nsIFrame * 0x01707eb4, nsFrameItems & {...}) line 6970 + 56 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dcae50, nsIFrame * 0x01707eb4, int 1, nsFrameItems & {...}, int * 0x00124654) line 13224 + 69 bytes nsCSSFrameConstructor::ConstructInline(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dcae50, nsIFrame * 0x01718e48, nsIStyleContext * 0x0171ee30, int 0, nsIFrame * 0x01707eb4, nsIFrame * * 0x001249d4, nsIFrame * * 0x001249a4) line 13008 + 38 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dcae50, nsIFrame * 0x01718e48, nsIStyleContext * 0x0171ee30, nsFrameItems & {...}) line 6321 + 53 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dcae50, nsIFrame * 0x01718e48, nsIAtom * 0x00b44cf0, int 3, nsIStyleContext * 0x0171ee30, nsFrameItems & {...}, int 0) line 7102 + 45 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dcae50, nsIFrame * 0x01718e48, nsFrameItems & {...}) line 6970 + 56 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc8270, nsIFrame * 0x01718e48, int 1, nsFrameItems & {...}, int * 0x00124c3c) line 13224 + 69 bytes nsCSSFrameConstructor::ConstructInline(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dc8270, nsIFrame * 0x0171abfc, nsIStyleContext * 0x01706520, int 0, nsIFrame * 0x01718e48, nsIFrame * * 0x00124fbc, nsIFrame * * 0x00124f8c) line 13008 + 38 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dc8270, nsIFrame * 0x0171abfc, nsIStyleContext * 0x01706520, nsFrameItems & {...}) line 6321 + 53 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc8270, nsIFrame * 0x0171abfc, nsIAtom * 0x00b44cf0, int 3, nsIStyleContext * 0x01706520, nsFrameItems & {...}, int 0) line 7102 + 45 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc8270, nsIFrame * 0x0171abfc, nsFrameItems & {...}) line 6970 + 56 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02d95040, nsIFrame * 0x0171abfc, int 1, nsFrameItems & {...}, int * 0x00125224) line 13224 + 69 bytes nsCSSFrameConstructor::ConstructInline(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02d95040, nsIFrame * 0x0171b8dc, nsIStyleContext * 0x0171e374, int 0, nsIFrame * 0x0171abfc, nsIFrame * * 0x001255a4, nsIFrame * * 0x00125574) line 13008 + 38 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02d95040, nsIFrame * 0x0171b8dc, nsIStyleContext * 0x0171e374, nsFrameItems & {...}) line 6321 + 53 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02d95040, nsIFrame * 0x0171b8dc, nsIAtom * 0x00b44cf0, int 3, nsIStyleContext * 0x0171e374, nsFrameItems & {...}, int 0) line 7102 + 45 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02d95040, nsIFrame * 0x0171b8dc, nsFrameItems & {...}) line 6970 + 56 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc5520, nsIFrame * 0x0171b8dc, int 1, nsFrameItems & {...}, int * 0x0012580c) line 13224 + 69 bytes nsCSSFrameConstructor::ConstructInline(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dc5520, nsIFrame * 0x0171d2d4, nsIStyleContext * 0x0171ee9c, int 0, nsIFrame * 0x0171b8dc, nsIFrame * * 0x00125b8c, nsIFrame * * 0x00125b5c) line 13008 + 38 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x01703770, nsIContent * 0x02dc5520, nsIFrame * 0x0171d2d4, nsIStyleContext * 0x0171ee9c, nsFrameItems & {...}) line 6321 + 53 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc5520, nsIFrame * 0x0171d2d4, nsIAtom * 0x00b44cf0, int 3, nsIStyleContext * 0x0171ee9c, nsFrameItems & {...}, int 0) line 7102 + 45 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc5520, nsIFrame * 0x0171d2d4, nsFrameItems & {...}) line 6970 + 56 bytes nsCSSFrameConstructor::ProcessInlineChildren(nsIPresShell * 0x02d913c0, nsIPresContext * 0x02d605a0, nsFrameConstructorState & {...}, nsIContent * 0x02dc2f60, nsIFrame * 0x0171d2d4, int 1, nsFrameItems & {...}, int * 0x00125df4) line 13224 + 69 bytes nsCSSFrameCons --> Layout
Assignee: harishd → attinasi
Component: Parser → Layout
QA Contact: moied → petersen
I have a fix for this in bug 56894. The problem is the page has a lot of block elements inside of inline elements, and this causes some really pathetic behavior when the content is appended. We basically end up repeatedly reframing the containing block of the appended element, and recurse forever. Marking dependency on 56894, which has the patch.
Assignee: attinasi → attinasi_layout
Depends on: 56894
Target Milestone: --- → mozilla1.0
Marc's patch seems to have fixed things here using a 2002-01-29-06 branch build under W2K.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: