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.
We're running NB 5 on Solaris 9 machines. It's just the plain-jane Netbeans IDE. We use it for editing, compiling and running. We have 8 or 10 small files open at a time. Multiple times during the day, the drop down menus go blanks and and we have to save all of our files, exit and restart netbeans. All the startup options for netbeans are at their defaults. I had hoped that upgrading from netbeans 4 to netbeans 5 would have fixed this problem, but it hasn't. Got any solutions? -- Will
Can you please specify what JDK do you use to launch NetBeans 5.0 on the Solaris 9 ? Performance guys, can you please follow up with wpherigo ?
Are you working with forms? Can you provide memory usage histogram (jmap -histo <pid>, you'll get pid by running jps) at the point IDE becomes unusable, or even better a memory dump (jmap -dump:format=b,file=nb.hprof <pid>, but the dump's size could easily be around 100MB)
From wpherigo: Do you mean gui forms? Not usually. This generally happens 5 or six times a day with, say, 4 to 6 files open and doing a series of compile and edits to fix the problems. After you do that for an hour or two, all the pull downs go blank and you have to ctrl-s any unsaved files and then alt-f4 to close Netbeans. We moved from Netbeans 4 to Netbeans 5 because we figured that such memory problems had been fixed. Anyway, I'll do as you have suggested and see what we can provide you with. Unfortunately, we have some significant restrictions on what we can release outside of our network, but I'll do the best I can to provide you with any helpful information. We are using standard configuration settings, by the way. Would it be helpful to increase the heap sizes, or would that just move the problem off?
Note: the fact that "the drop down menus go blanks" does not directly suggest a memory leak as the problem. What does the memory meter say? (enable it by right click to toolbar and check of the "Memory" checkbox) In case the memory meter indicates it is a memory leak, heap histogram would be very helpful and safe (contains no vital info about your code). Heap dump, on the other hand, contains e.g. the content of all opened editors... In any case, please attach the IDE log ($userdir/var/log/messages.log). Please keep the communication inside issuezilla. Thanks.
Our JDK is 1.5. We don't currently have the memory meter enabled, but we can do that.
marking as incomplete for now...
pnedjedly wrote: "Note: the fact that "the drop down menus go blanks" does not directly suggest a memory leak as the problem." What does it suggest? I am running with the memory meter now. What do I need to look for?
> What does it suggest? There are several kinds of bugs that can manifest themself this way. There would be an OutOfMemoryException logged if it was caused by escalated memory leak. There can be any other exception thrown during menu processing that would break the paint as well. All such issues should end up logging the cause into the IDE's log file ($userdir/var/log/messages.log). If you reproduce the behaviour, please attach the log file.
Possibly related, I've been getting OutOfMemoryErrors from NB 5.5 beta 2 using JDK 1.5.0_06 on Solaris 10. I have a histo, which I shall attempt to attach.
Created attachment 32382 [details] Histo of NB 5.5 out of memory on Solaris 10
From the histogram, it is obvious that most memory was consumed by javac ASTs. What can't be seen from the histogram is why. Let me ask additional questions: What were your actions before the OOME happened? How many editors did you have opened. Would it be possible to generate complete heap dump and publish it somewhere?
I finally have a dump, without anything sensitive in it. This particular dump happens to have a debugged process running, but in most cases it has happened with a very simple edit-compile-run cycle on a very small program. The memory meter suddenly shoots up from nothing. The dump is around 130 MB. I'm not sure on a good way to publish that. [Note: I'm not the original reporter of this bug.]
Javacore module was replaced by Retouche infrastructure. This bug is not valid in trunk any more.
Reorganization of java component