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.
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
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?
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 :) )
> 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.
BTW: Which kind of filesystem do you use?
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 :-(
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.
Approved
Approved by QA.
Waiver approved.
I lowered prio to P2, because the problem is not well reproducible.
(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...
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, ...)
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.
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?
Blackdown 1.3.1_02a-FCS has the same bug
I am closing this bug report as WONTFIX. It does not contain enough information to be useful.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.