665628 - Memory leaks with jQuery in FF 4

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Len]

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

Comment 1

[Len]

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

Comment 2

[AndreiD[QA]]

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/

Comment 3

[Nicholas Nethercote [inactive]]

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.

Comment 4

[Len]

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?

Comment 5

[Nicholas Nethercote [inactive]]

(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.

Comment 6

[Marco Castelluccio [:marco]]

Do you still see this issue with 8.0a2?

Comment 7

[Nicholas Nethercote [inactive]]

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.