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.0 (Build 200711261600) VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05 OS: Windows XP, 5.1, x86 User Comments:
Created attachment 55228 [details] stacktrace
Created attachment 55245 [details] stacktrace
Build: NetBeans IDE 6.0 (Build 200711261600) VM: Java HotSpot(TM) 64-Bit Server VM, 1.6.0_03-b05 OS: Linux, 2.6.23-gentoo-dfa, amd64 User Comments:
Created attachment 55377 [details] stacktrace
*** Issue 125366 has been marked as a duplicate of this issue. ***
Build: NetBeans IDE Dev (Build 200801310006) VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05 OS: Linux, 2.6.22-14-generic, i386 User Comments:
Created attachment 55881 [details] stacktrace
Dane, please take a look at AbstractRefactoring.createProblemAndLog
Build: NetBeans IDE 6.0 RC2 (Build 200711201000) VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05 OS: Windows XP, 5.1, x86 User Comments:
Created attachment 55936 [details] stacktrace
Build: NetBeans IDE Dev (Build 200802110004) VM: Java HotSpot(TM) Client VM, 1.6.0_03-b02 OS: Windows XP, 5.1, x86 User Comments: Tried find usages on SetExecutionUriAction, with some netbeans modules opened
Created attachment 56612 [details] stacktrace
Build: NetBeans IDE 6.0 (Build 200711261600) VM: Java HotSpot(TM) Client VM, 1.6.0-b105 OS: Windows XP, 5.1, x86 User Comments:
Created attachment 57304 [details] stacktrace
This issue has already 20 duplicates
Build: NetBeans IDE Dev (Build 200803170003) VM: Java HotSpot(TM) Client VM, 10.0-b19 OS: Linux, 2.6.24-12-generic, i386 User Comments: I moved JFrame form from one package to another one. Exception speaks about a memory, but it does not seem possible at this moment...
Created attachment 58596 [details] stacktrace
Dane, please fix this one. It has many duplicates. Thanks
Fixed in 988ce607c302.
I am forced to reopen this issue because it still persists in RC 6.1. Product Version: NetBeans IDE 6.1 RC1 (Build 200804100130) Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) There seems to be problem with move/refactor of more files when some file contains bad reference (i.e. imports package that does not exist). 1. I selected more files within one project (one with bad reference). 2. I dragged them to another package (Projects view) [screenshot1]. 3. "Move Classes" Dialog appeared. I pressed "Refactor" button [screenshot2]. 4. Some strange* error was displayed. After that exception was thrown [screenshot3]. *I would not say there is not enough memory or that the source tree is too large (you can see, it is really small).
Created attachment 60491 [details] screenshot 1
Created attachment 60492 [details] screenshot 2
Created attachment 60493 [details] screenshot 3
This issue has already 50 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=13304
Honzo, please take a look at it. Some hacking needs to be fine tuned in AbstractRefactoring.createProblemAndLog. Thanks.
kate: I have tried to reproduce your case and it works with NB 6.1 and later. Please try it again with released NB 6.1 and released JDK 1.6.
I have found steps to reproduce it. In case a refactoring action e.g. Move Class is invoked repeatedly memory starts to grow rapidly then. Even the refactoring runs on simple project without dependencies. According to the memory profiler it seems that there are plenty of javacs kept by soft references. We should find out 1) who creates them and 2) why JMX Beans report them as insufficient memory.
The root of this problem seems to be the timers module and namely InstanceWatcher.FinalizingToken class. This class implements Object.finalize() method that prevents javacs to be garbage collected as expected. Problems disappeared after disabling the module. I am a bit surprised the module is part of NB 6.1 FCS. Anyway reassigning to apisupport/timers to resolve it.
I don't understand your evaluation. First, timers don't use soft references at all, only weak references, which never* prevent GCing of the referenced objects. And second, InstanceWatcher.FinalizingToken doesn't hold on any other instance, it is just a random (single) instance with finalize method - there are much more finalizable instances on the heap all the time. Where are those soft references really comming from? Note: I'm not saying that timers module is not triggering this problem, I just want to know more... The best solution would probably be to issue an update with this module disabled by default. *) Well, I can imagine WeakReference being able to prevent cleaning the objects during scavenge...
BTW: What if you issued an explicit gc() in such case and retry?
First I thought it is some SoftReference since the javac was released after filling the whole memory. Forcing GC sooner did not help. VisualVM was not able to find a GC root. Later, as I wrote above, the only suspicious references that I found were from InstanceWatcher (JavacTaskImpl<-...<-InstanceWatcher.FinalizingToken<-Finalizer) and you are right that they are weak. The solution was to disable the timers module. The problem disappeared immediately. BTW InstanceWatcher.FinalizingToken DOES hold other references since it is not static nested class.
> The best solution would probably be to issue an update with this module disabled by default. Yes, that is exactly what we want to do for the time being.
Cc'ing sustaining.
Created attachment 63432 [details] Patch
As discussed with pflaska, there should be no dependency on timers module and the module should be used only for internal profiling of the IDE. So there should be no objections to disable it.
patch is verified in current trunk
I did two changes in trunk: -changed InstanceWatcher to use WeakReference+Utilities.activeReferenceQueue - cleaner, and will hopefully play nicer with GC. http://hg.netbeans.org/main/rev/7a73ff20b869 -the module is non-functional (Logger handler not registered+icon in the Memory toolbar hidden) when assertions are off. The overhead of the module in the release should be therefore negligible. Can be overridden by a command line property. http://hg.netbeans.org/main/rev/14831576319b
Integrated into 'main-golden', available in NB_Trunk_Production #292 build Changeset: http://hg.netbeans.org/main/rev/7a73ff20b869 User: Jan Lahoda <jlahoda@netbeans.org> Log: #125531: do not use finalizers.
I recommend jlahoda's #14831576319b (dynamic enablement of module's UI) be reverted, as well as Tonda's recent #d94a37ba3d4c (hide of module from Plugin Manager), and that the module just be moved to the update center and out of the build. If you want it, you install it and its UI appears, just like with other optional modules potentially useful to NB developers (Project Metadata Inspector, System Properties, ...); if you want to turn it off or delete it, you do so from PM like with any other functionality.
In particular, the current state is broken: http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/1958/testReport/org.netbeans.nbbuild/VerifyUpdateCenter/testAutoUpdateVisibility/ Some regular modules (that no one depends on) neither AutoUpdate-Show-In-Client nor AutoUpdate-Essential-Module org.netbeans.modules.timers
Build: NetBeans IDE Dev (Build 200807291401) VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06 OS: Linux, 2.6.24-20-generic, i386 User Comments: Stacktrace: java.io.IOException at org.netbeans.api.java.source.JavaSource.runModificationTask(JavaSource.java:992) at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:244) at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:231) at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin.prepare(JavaWhereUsedQueryPlugin.java:200) at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:380) at org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:202)
Created attachment 66115 [details] stacktrace
Build: NetBeans IDE Dev (Build 200807301401) VM: Java HotSpot(TM) 64-Bit Server VM, 10.0-b22, Java(TM) SE Runtime Environment, 1.6.0_06-b02 OS: Linux, 2.6.25-9.slh.1-sidux-amd64, amd64 User Comments: Stacktrace: java.io.IOException
Created attachment 66197 [details] stacktrace
Created attachment 66503 [details] Patch against release61_fixes.
Created attachment 66504 [details] Built module with the patch, from release61_fixes.
Patch against release61_fixes: http://www.netbeans.org/nonav/issues/showattachment.cgi/66503/125531.diff Built module for QE evaluation: http://www.netbeans.org/nonav/issues/showattachment.cgi/66504/org-netbeans-modules-timers.jar
patched jar tested with 6.1. The timers are gone after applying the new jar ->fixed, verified
v
I've imported tha attached changeset http://www.netbeans.org/nonav/issues/showattachment.cgi/66503/125531.diff into release61_fixes repository as http://hg.netbeans.org/release61_fixes/rev/ba805dd42fab
verified in patch3 (2008-08-12_03-59-31)