366083 - 2 Memory Leaks with opening event window

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[matthaeus123]

This leak was found by using David Baron's "Leak Monitor". There are 2 JavaScript related memory leaks. The leaks are related to this file "chrome://calendar/content/datetimepickers/datetimepickers.xml".

Description: After the "Create New Event" and/or "Edit Event" window is closed, the memory is not reclaimed and the objects are still being held by native code. 

The 2 sources of the leaks are below:

Leaks in window 0x3561200:
[+] [leaked object] (35ee420, chrome://calendar/content/datetimepickers/datetimepickers.xml, 363-371) = [Function]
 [ ] prototype (17697c0) = [Object]
[+] [leaked object] (35ee3a0, chrome://calendar/content/datetimepickers/datetimepickers.xml, 398-407) = [Function]
 [ ] prototype (1769760) = [Object]

Steps to reproduce:

1. Start Sunbird.
2. Check initial system memory usage.(Mine is 24,800k)
3. Create a new event, when new window pops-up, press cancel.
4. Check current system memory usage. (Mine is 26,604k)
5. Repeat steps #2-#4 for further proof of the leak.

What should of happened: The memory used to open up the event window should have been reclaimed,and the memory usage should have returned to the same amount, which was used when the program was started.

Steps to fix problem: Rewrite the code from the lines of code shown above, so that the memory used to open the "event windows" ("Edit Event" and "Create New Event") is reclaimed after the window is closed.

This was experienced with:  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a2pre) Gecko/20070105 Calendar/0.4a1

Comment 1

[Joey Minta]

These leaks are the event listeners, which aren't being removed on destruction of the node.

Comment 2

[matthaeus123]

Sorry, I forgot that this also applies to creating and editing tasks. The leak detector gives practically the same leak warning as the leak caused by creating or editing an event. More examples of the leak are below.


Here are 2 more reports of this memory leak:

1.
Leaks in window 0x263bb80:
[+] [leaked object] (264b820, chrome://calendar/content/datetimepickers/datetimepickers.xml, 398-407) = [Function]
 [ ] prototype (13f3e20) = [Object]
[+] [leaked object] (264b960, chrome://calendar/content/datetimepickers/datetimepickers.xml, 363-371) = [Function]
 [ ] prototype (13f3de0) = [Object]

2.
[+] [leaked object] (265c600, chrome://calendar/content/datetimepickers/datetimepickers.xml, 363-371) = [Function]
 [ ] prototype (13f3d40) = [Object]
[+] [leaked object] (265c580, chrome://calendar/content/datetimepickers/datetimepickers.xml, 398-407) = [Function]
 [ ] prototype (13f3d20) = [Object]


This was experienced with:  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
rv:1.9a2pre) Gecko/20070105 Calendar/0.4a1

Comment 3

[matthaeus123]

(In reply to comment #1)
> These leaks are the event listeners, which aren't being removed on destruction
> of the node.
> 

Just to make sure, you concur with the fact that this is a bug right?

Comment 4

[Joey Minta]

(In reply to comment #3)
> Just to make sure, you concur with the fact that this is a bug right?
> 
Sure.  There's code on the trunk that should prevent these leaks from actually being harmful, but they should be fixed anyway.  And it will make a real difference for Lightning in Thunderbird 1.5.

Comment 5

[Matthew (lilmatt) Willis]

Attachment: Removes the listeners

Comment 6

[matthaeus123]

(In reply to comment #4)
> (In reply to comment #3)
> > Just to make sure, you concur with the fact that this is a bug right?
> > 
> Sure.  There's code on the trunk that should prevent these leaks from actually
> being harmful, but they should be fixed anyway.  And it will make a real
> difference for Lightning in Thunderbird 1.5.
> 

Well, I know that one of the biggest complaints with Mozilla software is memory leaks. I'm just trying to help out and make leaks as minimal as possible.


BTW, the new patch works perfectly, and I was wondering when this patch would appear in the builds.

Comment 7

[Joey Minta]

Comment on attachment 250641 [details] [diff] [review]
Removes the listeners

nice, r=jminta and thanks for a good clean bug report! :)

Comment 8

[Matthew (lilmatt) Willis]

Patch checked in on MOZILLA_1_8_BRANCH and trunk

-> FIXED