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.
After upgrading a 3.4.1 installation to 3.5 (q-build NetBeansIDE-release35-QBE200303252350-200304031325.zip), running refresh recursively, quitting and restarting NB, a background thread always ran. NB consumed 100% CPU time, was usable, but slow. Restarting NB several times did not help. Deleting the VCS cache directory solved the problem. This only happened on one machine so far. Using JDK 1.4.2 Beta. Attaching thread dump from the situation.
Created attachment 9771 [details] Thread dump
This looks like a serious problem. Thanks for the thread dump!
New problem on the same PC. Starting takes again very long and then there is an exception. After that, working is possible with NB. Attaching the error text.
Created attachment 9791 [details] Errors during startup.
At the end of the errors there's: [catch]Caused by: java.lang.OutOfMemoryError ==> [catch]java.lang.OutOfMemoryError The exception's stack looks pretty the same as in the first thread dump. This bug seems to create an infinite thread, that ends with OOME.
Can you reliably reproduce it Thomas ? I am afraid we won't be able to confirm whether a fix is successful or not here in Prague.
I hope I've fixed the problem in the main trunk: /cvs/vcscore/src/org/netbeans/modules/vcscore/objectintegrity/VcsObjectIntegritySupport.java,v <-- VcsObjectIntegritySupport.java new revision: 1.10; previous revision: 1.9 /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.221; previous revision: 1.220 /cvs/vcscore/src/org/netbeans/modules/vcscore/FileObjectExistence.java,v <-- FileObjectExistence.java initial revision: 1.1 But I'm not able to reproduce the bug (I've detected where is the problem from the thread dump only), so I'm not able to verify whether this fix really helps. Thomas, can you please describe exact steps how to reproduce this? I'll attach a binary patch, so that you will be able to verify whether it's fixed.
Created attachment 9851 [details] The binary patch. To apply, copy into <NB-install>\modules\autoload\patches\org-netbeans-modules-vcscore\ folder and copy Patch32731.jar into it. Verify in ide.log, that the patch was applied.
It's a colleague, who has this problem. I'll ask him when he returns on monday.
Okay, thanks. We really need it, otherwise it can't be integrated into NetBeans 3.5, because of high resistance mode.
The problem did not happen anymore. Seems that it has resolved itself somehow.
Okay, I propose then to decrease priority accordingly and waive this for NetBeans 3.5/Sun ONE Studio 5.0.
The problem is, that this is apparently not easily reproducible. But when it happens it has quite bad consequences. But when we can not reproduce the problem, we can not integrate the fix in high resistance mode, because we're not sure that it's fixed. So I'm downgrading this to P2 until we find steps how to reproduce it.
Adding S1S5_WAV keyword. Due to the fact that this problem is not reproducible any more, I'm asking to waive this issue for integration in S1S 5.0 / NB 3.5.
I think we have this problem here with 3.5 RC3 again. We have saved the user directory, if you need it. Should we try the patch? Attaching new thread dump. Reopened and raised to P1.
Created attachment 10527 [details] New thread dump.
This is fixed. But only in 4.0 (dev sources) - Target Milestone is set to 4.0. There's attached binary patch, that should fix this problem in 3.5 builds. The fix did not get into 3.5, because we were not able to reproduce it. Even you've said: "The problem did not happen anymore. Seems that it has resolved itself somehow." Thus the problem is still there, but it probably happens wery rarely. This is why the fix was not approved for integration into 3.5 builds. The only solution for you is to install the attached binary patch.
As was said, I am sorry. Anyway we still appreciate your feedback if the patch works fine for you ...
Tried to apply the patch in NB 3.5 RC2 and got exception: java.lang.NoSuchMethodError: org.netbeans.modules.vcscore.objectintegrity.VcsObjectIntegritySupport.<init>(Ljava/security/PrivilegedAction;)V at org.netbeans.modules.vcscore.objectintegrity.IntegritySupportMaintainer.initVOIS(IntegritySupportMaintainer.java:81)
There were some more changes in the codebase after the patch was created. This is why it does not work. I'll create a new patch for NB 3.5 RC3... Patches are not the right way how to provide fixes to users anyway. We need a solution of issue #34132.
Created attachment 10603 [details] The new binary patch, that should work with NetBeans 3.5 RC3.
I am verifying this issue on behalf of Thomas hoping the patch has helped him.
In the meantime, we had some more cases of this bug and the new patch seems to fix the problem for NB 3.5 final.
Created attachment 11119 [details] The contextual diff that fixes this issue.
Created attachment 11120 [details] An additional file, that is necessary for this fix.
The fix is merged into release35_fixes branch: Checking in src/org/netbeans/modules/vcscore/FileObjectExistence.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/FileObjectExistence.java,v <-- FileObjectExistence.java new revision: 1.1.22.1; previous revision: 1.1 done Checking in src/org/netbeans/modules/vcscore/VcsFileSystem.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.207.2.14.6.1; previous revision: 1.207.2.14 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/vcscore/objectintegrity/VcsObjectIntegritySupport.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/objectintegrity/VcsObjectIntegritySupport.java,v <-- VcsObjectIntegritySupport.java new revision: 1.2.2.6.6.1; previous revision: 1.2.2.6 done
I can't reproduce it in Arrow SE6 2004Q1 on Solaris The fix seems to be fine.