From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8) Gecko/20010215 BuildID: 2001021505 When entering this URL into Mozilla, it first starts building the page but then grabs as much memory as possible and hangs around. I don't know how much he actually wants but I killed it at about 600MB. Reproducible: Always Steps to Reproduce: Just use above URL (I hate to acknowledge I copied this URL out of IE) Actual Results: Web page is started to be built, then hangs. In NT task manager you can see memory piling up. Expected Results: The usual memory consumption ...
I can confirm this with user agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010215 build: 2001021508 Before setting this to new I'm working on a testcase so I can better check for duplicates.
Also confirmed on 2001021503 0.8 build under Linux 2.2.18/glibc 2.1.2/XFree86 3.3.6
Ok, this seems to be the result of a misplaced </map> tag. Although it also depends on the way a couple of Table's and another <map> is. Changed summary from Mozilla grabs about, I don't know, 1GB of memory Changing OS to All per comments. Changing component to Parser from Layout.
Assignee: karnaze → harishd
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
OS: Windows NT → All
QA Contact: petersen → janc
Summary: Mozilla grabs about, I don't know, 1GB of memory → Hangs and starts eating memory on malformed html
Wow, this is a heavy one. And it eats more and faster then my dog.
Setting to m0.9.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
*** Bug 70011 has been marked as a duplicate of this bug. ***
r=heikki. A couple of suggestions, but you don't need to do these if you don't want. You have "PRBool(mHasOpenMap>0)", but the cast here is unnecessary since operator > returns a boolean. Also, the name "mHasOpenMap" is slightly misleading since it is no longer boolean - I would probably change it to something like mOpenMapCount or some such. I think there are other similar variables in the class suffering from this same misleading naming.
sr=vidur, seconding Heikki's renaming request.
updated qa contact.
QA Contact: janc → bsharma
Fix is in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Verified on: build: 2000-03-07-10-Mtrunk platform: WinNT The page loads fine.
Status: RESOLVED → VERIFIED
*** Bug 73500 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.