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.
Build: NetBeans IDE 6.5 Beta (Build 200808101001) VM: Java HotSpot(TM) Client VM, 11.0-b13, Java(TM) SE Runtime Environment, 1.6.0_10-rc-b26 OS: Linux, 2.6.24-19-generic, i386 User Comments: I used editor to edit the file from editor_tests project (TS_60_JavaEditor). I changed Members view in Navigator to Trees and back. IDE froze, OOM exception was thrown. Stacktrace: java.lang.OutOfMemoryError: Java heap space at com.sun.java.swing.plaf.gtk.GTKNativeEngine.finishPainting(GTKNativeEngine.java:493) at com.sun.java.swing.plaf.gtk.GTKPainter.paintTreeCellBackground(GTKPainter.java:1060) at javax.swing.plaf.synth.SynthTreeUI.paintRow(SynthTreeUI.java:557) at javax.swing.plaf.synth.SynthTreeUI.paint(SynthTreeUI.java:299) at javax.swing.plaf.synth.SynthTreeUI.update(SynthTreeUI.java:226) at javax.swing.JComponent.paintComponent(JComponent.java:763)
Created attachment 67002 [details] stacktrace
To reproduce: 1. Start IDE with a fresh userdir 2. Open project http://wiki.netbeans.org/attach/TS_60_JavaEditor/editor_tests.tar.gz 3. Open some files (3-4) and also the file "PerformanceBigJava.java" 4. While PerformanceBigJava file is opened, change item in Navigator combo to "Trees" and immediately after that back to "Members view" -> issue 140268, Navigator displays "Please wait" message 5. Wait until the Navigator refreshes, when it does, change the combobox item to "Trees" -> strange tree is displayed (see the screenshot) -> IDE responsiveness is very poor -> if you try to use a Navigator, you will eventually get above mentioned exception
Created attachment 67022 [details] Strange tree in Navigator view
java/navigation, not core/navigator! tzezula, note that due to bug 131951, java navigation panels may be created two times - however I don't know if there is any connection to this issue or not.
Trees (and Elements and Errors) panel is meant only for developers and is disabled in the release. I do not think this has anything to do with L&F.
*** Issue 143486 has been marked as a duplicate of this issue. ***
Created attachment 99162 [details] stacktrace Moved mouse over failure line in Test Results window, where the assertion message was apparently very long. (TopLoggingNbLoggerConsoleTest.testLog10000Lines)
My last report is likely a bug in the junit module, not this.
Created attachment 99165 [details] stacktrace
Created attachment 99924 [details] stacktrace
Created attachment 101545 [details] stacktrace changed to netbeans and clicked on editor while ftp upload was in progress
Created attachment 101565 [details] stacktrace switched from netbeans to other window while scanning project
This bug already has 250 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=67149
There are a few things to note: -this was originally reported against one of the Java support's debugging features (Trees panel in the navigator). As this is not an end-user feature, it is unlikely that this will be fixed (the NB developers should simply use a smaller source file when inspection through Trees is necessary). -OOMEs usually require heap dump to evaluate - OOME is not necessarily thrown from place with the actual problem. -the exception reporter joined many independent reports to this bug - I took a look at some of the stack traces, and some relate to the original report, some refer to classes from PHP, etc. Sorry, I do not have time to go manually through 250+ duplicates and split them to separate reports (esp. if the stack trace may not point to the actual problem). I think that the exc. reporter should handle OOMEs differently than the other exceptions: the IDE is set-up to auto-generate heap dump AFAIK, so tell the user where the heap dump is, so that he/she can keep it for further inspection. It would be good if heap histogram could be sent automatically with the report (usually not sufficient to fix the problem, but can be used to send the report to appropriate person for evaluation). The stack trace should also be kept, but not that much useful in most cases. Thanks.
Integrated into 'main-golden', will be available in build *201010060000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f2fc9756fbde User: Jan Lahoda <jlahoda@netbeans.org> Log: #143453: the java.debug's TreeNodes should consume less memory.
Everyone, does this still happen to you in NetBeans 7.0 Milestone 2 or later? If so, it would be useful if you could upload the heap dump generated by a recent build to some file sharing service and let us know. Thanks.
(In reply to comment #17) > Everyone, does this still happen to you in NetBeans 7.0 Milestone 2 or later? > If so, it would be useful if you could upload the heap dump generated by a > recent build to some file sharing service and let us know. Thanks. I didn't reproduce this for a long time ... but I'll attach dump if it occurs
I see that right now there is one occurrence from M2 build, by user kurris. http://statistics.netbeans.org/exceptions/exception.do?id=431194 kurris, can you please let us know whether this still happens to you, whether you can reliably reproduce, and if you have the heap dump, can you please upload it? Thanks.
Created attachment 102790 [details] stacktrace added 8-9 java source file externally to a project
This bug already has 400 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=67149
This seems to be resolved in 7.0 Beta. Good work guys!
Created attachment 105317 [details] stacktrace
There are now 13 reports of this problem from NB 7.0 Beta 2, we need to investigate these cases.
This bug already has 600 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=67149
Moving to performance to make sure this appears on the dashboard.
#494988 No heap dump, failed at JS (indexing) #494986 No heap dump, failed at JS (indexing) #494715 Corrupted gz, failed at Css (indexing) #494674 No heap dump, no usable stacktrace
#494657 No heap dump, failed at threading, some NPEs at PHP FTP #494304 Corrupted gz, failed at JPDA #494016 Corrupted gz, failed at JS (indexing) #493353 Corrupted gz, failed at PHP parser #493351 Corrupted gz, failed at PHP parser
Created attachment 107104 [details] stacktrace typing hebrew in a properties file, fast.
Created attachment 107128 [details] stacktrace Typing hebrew fast, in a text file
pjiricka, so what is the status of this issue ? Any updates ?
This error occurs to me, when scanning a large drupal project (Build 201103230400). Memory usage jumps up to over 700mb very fast. IDE doesn't respond anymore. When I try to upload this issue incl. heapdump, another Memory error occurs and the upload is stopped. What do you need in order to analyse this better?
The same project uses only around 60mb in Netbeans6.9
> What do you need in order to analyse this better? Could you please upload the heapdump to some file sharing service so we can have a look?
Requesting a waiver for 7.0. Not able to analyze the heapdumps, and many of them are broken.
The heapdump is here: http://lars-pohlmann.de/netbeans/heapdump.hprof.gz User: netbeans Password: heapdump
Agree with waiver for NB 7.0. We'll do our best to address this issue in NB 7.0.1. larsomat: thanks for heapdump!
According the last attached memory dump it looks like problem in the HTML validator, because it eats alsmost 250 MB of ram. The problem can be in REPORTED_RUNTIME_EXCEPTIONS map, which is static and keeps anonymous inner classes "marker", but IMHO such anonymous class keeps reference into the enclosing whole instance of ValidationTransaction. Assigning to Marek, it his code.
(In reply to comment #38) > According the last attached memory dump it looks like problem in the HTML > validator, because it eats alsmost 250 MB of ram. The problem can be in > REPORTED_RUNTIME_EXCEPTIONS map, which is static and keeps anonymous inner > classes "marker", but IMHO such anonymous class keeps reference into the > enclosing whole instance of ValidationTransaction. > > > Assigning to Marek, it his code. filed as new issue 197166 - serious memory leak in html validator.
Integrated into 'main-golden', will be available in build *201103290400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c6b1d86726a9 User: Marek Fukala <mfukala@netbeans.org> Log: #143453 - fixed one of the many memory leaks reported in the issue. This one is described by Petr Pisl in the comment #38.
This bug already has 700 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=67149
Created attachment 107429 [details] stacktrace Editing a utf8 file, with mixed hebrew-english text. This happens if I type too fast.
This issue will be fixed on server side, until then I would like to keep it open.
Created attachment 108755 [details] stacktrace Copying from output window with lot of content
*** Bug 202245 has been marked as a duplicate of this bug. ***
Closing the issue - this issue comprises of all the OOME from very long period of time and it is practically impossible to analyze all the heap dumps. From now on all new OOME exceptions will be sorted into corresponding issues according to stacktraces. This will enable developers to better react to the new issues and not to be swamped by multiple different exception records in one big issue.
It would be useful to have a BZ query that lists the new bugs corresponding to the new incoming OOME exceptions.
Do you mean having something like http://netbeans.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=substring&short_desc=OutOfMemoryError%3A+Java+heap+space&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=STARTED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= linked from dashboard?