This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 41509 - Memory leak in enable/disable filter
Summary: Memory leak in enable/disable filter
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Action Items (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: tasklist-issues@contrib
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2004-03-30 15:32 UTC by Jan Lahoda
Modified: 2004-08-13 12:11 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Proposed patch, explicitly dispatching nodeDestroyed event (3.42 KB, patch)
2004-03-31 16:10 UTC, _ pkuzel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2004-03-30 15:32:22 UTC
Pre-RC2 build (200403291730), JDK1.4.2_03.

1. Set Tools/Options/Editing/TODO Settings/List
Limit to 1000.
2. Open the TODO window, select "Selected Folder"
and choose a folder with at least 1000 TODOs.
3. Wait until it is scanned.
4. Force GC a few times (using Memory toolbar,
preferably).
5. Define a such filter that most of the TODOs are
left in the view.
6. Switch enable/disable filter a few times (10).
7. Force GC.
8. More memory is consumed than was in step 4,
although it should not be.

It seems that the leak is approx. 1MB per
1000TODOs per one enable/disable.
Comment 1 _ rkubacki 2004-03-31 12:38:51 UTC
Tried on 200403301730 build, J2sdk1.4.2_04, Linux RH9.

Mounted ant-1.5.4 sources (src dir) and performed search on root
folder. It returns 107 todos, added filter that rejects 3 items (TODO,
@todo, XXX). 
After 1st scan the memory meter shows 16.7MB
one filter enable/disable - 17.2
next enable/disable - 17.6
next 3 enable/disable - 18.6
next 3 enable/disable - 19.5
next 3 enable/disable - 20.4
next 3 enable/disable - 21.1
next 3 enable/disable - 22.1

It gives ~300kB per one enable/disable with 100 todos (I do not know
in how many files).
 
Comment 2 _ pkuzel 2004-03-31 13:05:29 UTC
putting into profiler..
Comment 3 _ pkuzel 2004-03-31 15:54:41 UTC
There is missing call to TaskNode$1.nodeDestroyed() listener method.
This event is distribuded only by setKeys() call that does not occur
in this case.
Comment 4 _ ttran 2004-03-31 16:00:39 UTC
can someone explain how much this affects the user in real world
situations?
Comment 5 _ pkuzel 2004-03-31 16:10:21 UTC
Created attachment 14228 [details]
Proposed patch, explicitly dispatching nodeDestroyed event
Comment 6 _ pkuzel 2004-03-31 16:14:29 UTC
fixed in trunk

I do not plan backport to release36 until reopened at P1 with
justification.
Comment 7 Jan Lahoda 2004-04-28 16:46:52 UTC
Using trunk continuous build 20040428-1330, JDK1.4.2_04, Linux, it
seems that the leak is still here (or was re-introduced).
Comment 8 Ondrej Rypacek 2004-05-19 15:18:25 UTC
The bug was probably reintroduced by mi recent cleanup in nodes and
properties, which happened while Petr was fixing this. Now fixed in
trunk. Checked in 
tasklist/core/src/org/netbeans/modules/tasklist/core/TaskListNode.java

The diff is here:
http://tasklist.netbeans.org/source/browse/tasklist/core/src/org/netbeans/modules/tasklist/core/TaskListNode.java.diff?r1=1.6&r2=1.7

Comment 9 Jan Lahoda 2004-06-28 14:28:04 UTC
Seems OK in 200406271800.