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 19521 - Memory leak
Summary: Memory leak
Status: CLOSED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Petr Nejedly
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2002-01-17 10:53 UTC by rost
Modified: 2008-12-22 20:34 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rost 2002-01-17 10:53:21 UTC
Around every half an hour of heavy working with Explorer, Source Editor and Form
Editor I get an java.lang.OutOfMemoryError.

I already enlarged the values in ide.cfg substantially but it only delays the
problem.

There seems to be a very bad memory leak.

Greetings

Ronny
Comment 1 _ ttran 2002-01-17 11:37:04 UTC
it's hard to say what's the problem.  There are probably some leaks,
but you must tell us more info, so that at least we can guess where. 
What you're doing during that half hour?  Editing the source files? 
Editing the form?  Navigating around in the explorer?  How large are
your forms and java files?  How large are the mounted directories?

And which version of the IDE, JDK, OS you're using?
Comment 2 rost 2002-01-17 14:15:35 UTC
I reordered the structure of my program and had to reset all relevant
properties (icons, internationalized strings, ...).

So I used the explorer to choose the classes, the form editor to
choose the gui elements and the property editor to change the
settings. Over and over again :)

The project is, well, "quite" large. It's ~35k loc with some complex
forms. But that was never a problem with older versions of netbeans.

"du" says that the directory uses more than 7 megabytes of diskspace.
Because of the small size of all files I guess that the sum of the
file sizes is a lot smaller.

I use Blackdown's JDK-1.3. The rest is already filled in at the top of
this page (Linux, Netbeans 3.3.1-dev(200201170331))

Greetings

Ronny

PS: I'm very impressed with the responsiveness of the netbeans devel
team. Congratulations! (Now you just gotta fix the bugs :) )
Comment 3 _ ttran 2002-01-17 16:04:32 UTC
> I'm very impressed with the responsiveness of the netbeans devel
> team. Congratulations! 

thanks for the nice words

> (Now you just gotta fix the bugs :) )

Now the bad news, I don't believe that we'll be able to fix this leak
for 3.3.1 which is going into Release Candidate 2 tomorrow.  This kind
of bugs usually take a whole lot of time to chase down.

Comment 4 Petr Nejedly 2002-01-18 09:43:11 UTC
BTW: Which kind of filesystem do you use?
Comment 5 Petr Nejedly 2002-01-18 11:03:21 UTC
Oh, I was too fast on commit.
It is quite hard to track it here so I'd like to ask you for
some cooperation. Could you please enable the memory toolbar
(Right click in the toolbars, check "memory") and try to find
which particular operation causes memory usage to grow and
not allow it to shrink back (e.g using gc() button)?

The problem with tracking it here is that there can be e.g.
badly behaving bean which I don't have of don't test and that
could make NB misbehave. We had similar problem in form module
when manipulating JComboBox, but this it fixed already.

Of course the problem can be anywhere else :-(
Comment 6 Petr Nejedly 2002-01-18 13:42:30 UTC
Please approve this bug as 3.3.1 waiver, as it would
be very hard to even track the cause of this leak in the 3.3.1
timeframe.
Comment 7 iformanek 2002-01-18 13:47:37 UTC
Approved
Comment 8 Jan Chalupa 2002-01-18 13:57:58 UTC
Approved by QA.
Comment 9 eadams 2002-01-18 15:31:24 UTC
Waiver approved.
Comment 10 _ ttran 2002-01-21 07:34:00 UTC
I lowered prio to P2, because the problem is not well reproducible.
Comment 11 rost 2002-01-29 09:32:14 UTC
(Sorry for the delay, havent been here for a while...)

I enabled the memory toolbar, but wasnt able to pinpoint the culprit.
The changes where so minimal after each operation I couldnt see a real
difference. Over the long time the memory still fills up and cant be
gc'ed.

A problem may be that we use some inhouse beans here. I can not share
them :-(  What was causing the problems with the JCombobox?

Is there a way to "dump" the memory of the VM and analyze which
classes misbehave?

I would like to help more, but I have not much time to spare right now
as I have to work for my corporate masters :)

Can someone from the NetBeans crew please test if the problem exists
at their place, too? Just move the properties file of a large project
and start to remap everything manually (with Explorer, Source Editor,
Form Editor, Properties Editor) and watch the memory toolbar.

If everything is ok, I assume a bug in the inhouse beans, if not I
dont feel so alone :)

Greetings

Ronny Standtke

PS: I use reiserfs...
Comment 12 Petr Nejedly 2002-01-29 13:08:33 UTC
For the form editor leak, look at #11661.
The actual problem was that JComboBox/its model had a static variable
that held all the combobox instances and the instances held
the rest of the hierarchy. The hierarchy was fully regenerated
on every modification -> 1MB lost on each modification.

I'm currently investigating other things that may cause leaks
and fixing some of them so it may get better over the time.

To the filesystem: I meant the IDE filesystem, not the OS one :-)
That is, the way how did you mounted the sources.
You either did "Mount->Local Directory" or
"Mount->Version Control->something"

Dump:
You can run the IDE with hprof memory profiler on, the best settings
are: runide.sh -J-Xrunhprof:heap=dump,format=b,lineno=n,doe=n,depth=0
It will slow down the IDE, the above options are the least slowing
down but the IDE will still be 2x-3x slower (particulary for memory
allocation intensive tasks).
You can then generate memory dump using \^ (this will take ~20min),
it will be stored to java.hprof file. The file (~100MB?) will then
contain the whole image of your heap (including the sources open
in the editor) so will probably not want to send it to us.
You can look at it using HAT tool
(http://java.sun.com/people/billf/heap/), checking which class
instances hog the memory (big arrays, large number of instances of
a particular type, ...)
Comment 13 Tomas Pavek 2002-01-29 14:12:56 UTC
I have a suspicion about possible memory leak in form editor, but it 
does not seem to be so serious for me. Anyway - if you check the 
instances count please look also at number of
org.netbeans.modules.form.FormPropertyEditor objects.

Number of these instances could arise significantly when selecting 
various components in Component Inspector repeatedly.
Comment 14 Petr Nejedly 2002-02-05 12:20:39 UTC
I realized we're victim of a JDK memory leak from clipboard
operations, see
http://developer.java.sun.com/developer/bugParade/bugs/4531274.html
You're running on 1.3-class jdk from BlackDown which may be affected
as well. Could you try running the test from the bugparade please?
Comment 15 _ ttran 2002-02-15 14:25:22 UTC
Blackdown 1.3.1_02a-FCS has the same bug
Comment 16 _ ttran 2002-02-27 08:43:08 UTC
I am closing this bug report as WONTFIX.  It does not contain enough
information to be useful.
Comment 17 Quality Engineering 2003-07-01 16:00:47 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified.

Comment 18 Quality Engineering 2003-07-01 16:17:29 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.