User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 I have been struggling with some memory leaks using jQuery in FF4, and am looking for some help. I've read many articles on memory leaks, circular references, closures, etc. I think I'm doing everything right. But am still seeing memory increases in FF4 that just don't make sense to me. I've created a test case to showcase the issue. The test case basically has a large table of 500 rows, and users can click on each row to enter an inline edit mode where elements are appended using jQuery. When users exit inline edit mode, the elements are removed. The test case has a button to emulate 100 clicks for 100 rows to quickly magnify the issue. When I run it in FF4, I get very different behavior if I use "100 clicks slow" and "100 clicks fast". Emulating slow clicks has a peak increase of 8300KB and it takes a minute for it to settle down to 3300KB. Emulating fast clicks has a peak increase of 27,700KB, then it takes a minute to settle down to 4700KB. Note this is the exact same code that is executed, just with less delays between executing. A refresh and another run continues to increase memory at a similar rate. I classified this bug as critical since low memory machines can quickly run out of memory and crash or hang as a result. Reproducible: Always Steps to Reproduce: 1. Load test URL 2. Note Memory usage 3. Click "100 Clicks Fast" 4. Note memory usage while running 5. Note memory usage 1 minute after finished Actual Results: Peak Memory increases 27,700KB After 1 min, memory increase reduced to 4,700KB Expected Results: No memory increase after elements added and removed about:memory results for 3 points in time: Test page loaded Peak during "Fast 100" 1 min after "Fast 100" completes Memory Usage Overview Memory mapped: 38,797,312 65,011,712 56,623,104 Memory in use: 35,954,008 47,980,528 39,439,708 Other Information malloc/allocated 35,957,232 47,983,752 39,443,140 malloc/mapped 38,797,312 65,011,712 56,623,104 malloc/committed 37,699,584 55,189,504 46,800,896 malloc/dirty 299,008 2,629,632 3,530,752 win32/privatebytes 56,147,968 85,594,112 77,004,800 win32/workingset 74,076,160 110,723,072 102,264,832 js/gc-heap 4,194,304 13,631,488 5,242,880 js/string-data 537,278 554,434 554,408 js/mjit- code 61,438 403,392 426,988 storage/sqlite/pagecache 3,347,864 3,926,896 3,926,896 storage/sqlite/other 870,080 870,080 870,080

This bug might or might not be related: https://bugzilla.mozilla.org/show_bug.cgi?id=599694

Works for me on the latest Firefox Nightly Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110620 Firefox/7.0a1 Can you check if you still see this issue on the following build. Thanks http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Len, a number of leaks have been fixed since 4.0. As comment 2 says, can you try with a nightly build? That would be very helpful.

I ran it on 5.0, and that was slightly improved. While running the test, peak memory increase was about 30MB, settling after a minute after completing 5 runs to an increase of 7MB. I ran it in 7.0a1, and it was improved. The starting point was 10MB less. But while running the test, peak memory increase was still about 30MB, settling after a minute after completing 5 runs to an increase of 4MB. But should memory increase at all? If we are just adding and removing DOM elements, and the number of elements is the same at the end, why should there be any memory increase?

(In reply to comment #4) > > But should memory increase at all? If we are just adding and removing DOM > elements, and the number of elements is the same at the end, why should > there be any memory increase? It could be due to fragmentation.

Do you still see this issue with 8.0a2?

Based on the improvements mentioned in comment 4 and the general memory improvements we've had since 8, I'm going to assume this is fixed. Please reopen if that's not the case.