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.
Product Version = NetBeans IDE 3.4 RC 1 IDE Versioning = IDE/1 spec=2.23 impl=200207252340 Operating System = Linux version 2.4.18 running on i386 Java; VM; Vendor = 1.4.1-rc; Java HotSpot(TM) Client VM 1.4.1-rc-b18; Sun Microsystems Inc. Java Home = /usr/java/j2sdk1.4/sun/jdk1.4.1/jre System Locale; Encod. = cs_CZ; ISO-8859-2 Home Dir; Current Dir = /home.local/danielm; /DISKS/storage3/forte/NBdev-last/netbeans/bin IDE Install; User Dir = /home.local/danielm/NBdev-last; /home.local/danielm/.netbeans/3.4 ================================================================= I have mounted netbeans sources. And c. 10 fstreeview over it to have sources in apropriate classpath... Because of issue #23839 , I unmount my G-CVS FS and monted again with different pserver name (which is kind of allias to previous one). I remember after thet in RunTime TAB there were 2 nodes for one G-CVS FS:-( But OK. I continued work: I performed big checkout of those modules: core, openide, openidex, jemmy, jelly, jellytools, junit, xtest, vcscore, vcsgeneric, javacvs, diff and maybe others. Lot's of it has been already checkouted. Checkout command failed after it realy checkouted many of mentioned modules. And then IDE almost freeze... some NPE, OOME, etc Exceptions were thrown. see their stacktraces
Created attachment 6928 [details] stacktraces of 2 NPE
Created attachment 6929 [details] stacktraces of some additional E
The OOME is already mentioned in checkout performance issues. I'll fix the NPE.
The NPE is somewhat strange and might be caused by some inconsistent state caused by the OOME. Anyway it's fixed: /cvs/vcscore/src/org/netbeans/modules/vcscore/commands/CommandOutputCollector.java,v <-- CommandOutputCollector.java new revision: 1.11; previous revision: 1.10
And what's about the InvocationTargetException? BTW: even the NPE wasn't fixed:-( Or it somehow get broken... At least the performance is OK... But I have now very good PC (2GHz CPU, 1GB RAM :), so no OOME, but NPE and undeclaredExceptions still persist in NB351-RC1 #200307142350 And also, my whole CP has troubles for a few seconds when those Es were thrown... But they have different stacktraces, please se the attachment (all in one, if you don't mind:) Reproduction: ============== -I have mounted several JavaCVS and G-CVS FSs. -I also install the newest fstree module from update center... But I didn't use it 'cause repro is possible without using it (but might inflence the fact it is istaled?!?!?) -I've already had one G-CVS FS mounted where its' working dir was nb_all of all sources of the ide. -I deleted the content of this G-CVS FS from external tool (bash:) and invoked CVS->Checkout... -There I selected "standard" module and said I want release35 as a revision. -Well, the big checkout started.... Before it finished (or at the same time as it finished, not sure) the 2 Exceptions Windows popuped with NPE and UndeclaredE which I attaching as only one text attachment... Please investigate it, thanks
Created attachment 10998 [details] NPE and UndeclaredE (ITE) stacktraces
Probably because you delete the directory structure outside of NB this has affected the cache structure. Scheduling for NB 4.0.
*** Issue 24340 has been marked as a duplicate of this issue. ***
Depends on caching system re-design (issue #32089). This problem should be addressed by the re-design.
*** Issue 34813 has been marked as a duplicate of this issue. ***
Created attachment 13654 [details] stacktrace associated with issue
I'm still getting this issue in 3.6 RC1. Isn't this something we should fix before we go final?
Issue #32089 is scheduled for promotion D, after it will be resolved, this problem should disappear.
With patch there are constant memory requirements. On the other hand many files stay [local] after initial refresh recursivelly that pupulates cache files. They need to be refreshed again to show proper statuses. Most folders are marked [local] even after subsequent refresh. Most of inproperly annotated folders are in disk cache content. There is inconstency between disk cache content and it's visualization. Few of them is missing in disk cache content. There is inconsistency between disk cache content and real state (assuming the refresh should update it - it connects to server). Files are OK, but it would be better to show no status until known instead of current behaviour - marking them as [local] and rediplaying later on with proper status got from cache. It can flicker. So there are serious side effects that does not direclty link to actual code changes. At my level of understanding the code.
Ignore previous unrelated comment, please.
I can't reproduce this issue in fresh dev build 040924. Closing as worksforme.