632745 - JavaScript causes major memory leak and crash

Status: RESOLVED DUPLICATE of bug 617569

(Firefox :: General, defect)

Description

[Asbjørn Heid]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

By visiting the site mentioned Firefox will quickly consume the entire address space and eventually crash. If the tab is closed before it crashes, the memory is not reclaimed (causing it to use more than 2Gb of memory).

The script on the site works fine in Chrome 3.x and Opera 11.

Note, I'm not the author of the script, so I can't confirm the validity of the script. However even if the script is bad it should not cause Firefox to crash, and the memory should be reclaimed when the tab is closed.

Reproducible: Always

Steps to Reproduce:
1. Visit site, wait for it to load.
2. Wait for address space to be exhausted, typically less than 30 seconds on my machine.

Actual Results:  
The browser crashed.

Expected Results:  
Firefox should have terminated the JavaScript and reclaimed the memory without affecting any other tabs.

Comment 1

[timeless]

off topic: did you manually select x86_64? (because you're using the x86 version of firefox, which is what we care about).

stackwanted:
https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

you should try moving your other tabs to a new window and then closing the window which held your tab. we support <undo close tab> which means that just because you've "closed" a tab doesn't mean we can simply release its memory.

Comment 2

[c5496198]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre
OS: Windows XP SP3

I can reproduce this bug by simply visiting the url,
and firefox memory usage jump to 1GB.

Comment 3

[Soumya Deb [:Debloper]]

The for loop in main.js is causing the trouble.
the effort to buffer.push(0.0) for 320*240*3 times making the memory overflow.

It's not even getting out of the loop to the web-worker on x86; on x64 it's working, but very inefficiently.

I guess there is something not good about memory management.

Comment 4

[aravindm]

Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre

Able to reproduce the crashes.
Crash reports : 
bp-e641ea75-c88d-422a-b756-f3a222110209
bp-e820b79d-b65c-49e2-8402-2dd862110209
bp-8d10bf34-c22c-4683-97a5-b30042110209
bp-f6d8758a-def7-49e4-81c0-772b82110209

Comment 5

[Asbjørn Heid]

(In reply to comment #1)
> off topic: did you manually select x86_64? (because you're using the x86
> version of firefox, which is what we care about).

Yes, I assumed platform meant my platform since it asked for OS as well. I'll keep this in mind for the future.

>stackwanted:
I'll try to get a stack trace, but having some difficulty getting the nightly to crash while running through the debugger. Could appear as if the somewhat reduced performance helps the GC run, as it sometimes dips to 5-600MB, and then quickly rises to around 2-3GB again.

For what it's worth Chrome 3.0 and Opera 11.0 uses around 2-300MB and does not fluctuate wildly like FF does.