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.
Get Out of Memory exception after editing and testing for a few hours.
Created attachment 19010 [details] IDE Log file showing memory exceptions
The problem has gotten worse as the code has gotten bigger. Now, within 15 minutes, the editor and my whole system slows down and within 30 minutes, I get the Out Of Memory exception. After the first use of the editor provided list of object methods etc, java.exe starts using 99% of the CPU time. This usage continues until and after the Out Of Memory exception (often during a compile). On one occasion, the slow down was so severe that I couldn't even get the XP task manager up and had to reboot the system (and lost the changes that I had made).
Try to the latest Netbeans 4.0 RC (RC 2 available at the end of this week), some improvements were integrated. If you encounetered a problem again, feel free to reopen the issue and attach relevant information (steps, ide log). Thanks!
Created attachment 19149 [details] Log file showing Out Of Memory Error in 4.1EA1
The out of memory problem re-occurred on the next version of netbeans. The problem of stalling the computer was not experienced, but the Out Of Memory occurred within half an hour of start of editing of the long program.
Can you be more specific what activity causes the problem? To identify the source we would need to know what part should be responsible - editing (what files?), execution, debugging and so on. You can turn on memory toolbar to track current heap usage. For a large project you can tune memory settings as described in http://performance.netbeans.org/howto/jvmswitches/index.html
Also what is your hardware and OS?
The operating system is Windows XP SP2. I was editing a file - adding code to the function ForceButton6ActionPerformed(). The file is about 4100 lines long. The main project contains another small file and refences another project that interfaces with a C++ DLL library. The code runs and tests successfully to the extent that it is completed. Running the code does not seem to cause the problem, it appears that after a variable number of edits the system slows down and shortly afterwords, if I don't exit, the Out Of Memory occurs. I can make the projects available for testing/debugging if requested.
Do you use form (GUI) editor?
The project was built using the GUI editor, but I have not made changes to the GUI for a while. It created 196 swing objects and InitComponents() is 2059 lines long. The computer has a 1,024 MB of memory, available after XP 655.61 and virtual memory of 2.0 GB. Using a demo version of TaskInfo2003, I find that only about 296,000 bytes of memory are used when the system slows down but the number of 'handles' of 1,873 is much larger than anything else on my computer and the CPU usage is over 97%.
I suggest you to increase the limit for Java heap with -Xmx option as desribed in linked document. This will improve overal performance on your system. I am reassigning the bug to form editor for further evaluation. It is not clear yet if it is scalability problem (4100 lines is acceptable for our Java editor but form can add significant additional overhead) or wherther it is a leak.
I doubt it has anything to do with form editor (the reporter hasn't modified the GUI for a while). The following symptoms point to java module => reassigning for evaluation. > After the first use of the editor provided list of object > methods etc, java.exe starts using 99% of the CPU time. > This usage continues until and after the Out Of Memory > exception (often during a compile).
Could you please verify this with the latest 4.0 RC build (rc2)? The 4.1ea1 is almost as old as 4.0beta2 - there have been some significant improvement made in the memory usage in the rc2. How many classes do you have (approximately) in your project? How many other project do you have open in the IDE? Do you run out of memory even if you increase the max. heap size (using -Xmx setting)?
THe new version, netbeans-4.0rc2, seems to have fixed the problem.
It is not fixed. There is still leak. NB trunk build from Dec 8, JDK 5.0u1-b06 and with reporter's form it retains more than megabyte after form open, editing of source, close. I do not know if I need to edit, maybe it does not depend on this.
Does this happen when editing a plain Java? Or only with forms? Does the memory grow with opening and closing the file repeatedly, or the increased usage of memory is a one-time thing and can be caused by the fact that more classes get loaded when opening a form or that 2 ASTs get cached when a file is open?
I will attach some interesting traces showing various ways how the data can be held and fill more bugs to track them separately. To briefly comment them: 1) there is a thread keeping all top level windows to clear them on shutdown held by TopThreadGroup, number of these windows is growing in time and they keep some resources (including FormDesigner through pallete). I need to investigate. 2) cell renderers holding the panel -> TC -> FormDesigner, this is known issues of JDK that can be workarounded 3) org.netbeans.modules.editor.NbToolTip$Request listening to org.netbeans.modules.debugger.projects.ToolTipAnnotation 4) FindDialogSupport in editor holding editor pane -> TC -> FormDesigner 5) org.netbeans.modules.form.FormLAF.ideDefaults hold another instance of FormDesigner
Created attachment 19237 [details] traces to FormDesigner from roots
It seems that none of these issues have anything to do with java module. Which module should I reassign this to?
Reassigning back to form, since this has nothing to do with java module and one of the reference traces points to FormLAF.ideDefaults (note there is a separate issue filed for the editor leak related to this).
I also have problems with out of memory error. Strange is, that memory meter shows 100/178MB free.
Yes, one of the reference traces points to FormLAF.ideDefaults, but this field is a Map that points to the same objects as UIManager's defaults map. So, the question is how something (NbToggleLineNumbersAction?) that holds a reference to FormEditorSupport$JavaEditorTopComponent has been inserted into this map. There are also other traces ending in the editor module => reassigning to editor for evaluation.
Re Honza Becicka: it can be OK. OOME can be thrown under various circumstances. The most often one is lack of space on Java heap. Another possibility is full permanent area or problems with parallel GC. If there was really only 100 of 178 used than it can be very likely permarea. What platform do you run on? We can track this problem (perhaps in a separate issue). re Honza Stola: it is not editor problem. The form module deeply copies the content of map. Form maintainers should justify this. Why form needs to keep this data?
I'm using windows xp.
According to the last Radim's note reassigning back to form for evaluation.
We will check the suspicious traces in form as soon as possible, together with issue 52287. These issues should be resolved for 4.1.
FormDesigner is no longer held in memory after fix of issue 52286 => closing.
verified