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.
NB Dev (200608101800), JDK 6.0 (b94) Linux Ubuntu 5.06, Gnome 2.0 Steps to reproduce: - run IDE - create new Java Application project - push from popup menu over the "javaaapl...." (default package) node New | JFrame Form - push FInish button -> IDE freezes (see attached thread-dump)
Created attachment 32806 [details] thread-dump
reassigne to java / javacore
Ups it isn't frozen, it just finished (after ~ 2-3 minitues on TM 8104/2GHz/1GB RAM)
This version NetBeans IDE Dev (Build 200608081800) is still Ok but all other later builds causes this bug. It is sufficient to create more than one JFrame in one package and then you have to wait for a 3 and more minutes till the new JFrame is created.
I've been told to write here that it works fine with NB 5.5 (200608110000)
There were only 3 commits to javacore since 200608081800: 80740, 81504, 76297. All these commits seems to be bulletproof. It looks like someone else introduced this regression. I saw some commits into the wizards... Reassigning for evaluation.
The only change in the NewJavaFileWizardIterator.java is that the wizards does not create package when they are cancelled. It shouldn't have any effect on this. If this is not deadlock, the attached thread dump is not enough. We need at least 2 successive thread dumps with some small delay to see where the IDE is frozen.
I am also concerned with the number of "Timeout waitFinished compatibility processor" threads which are waiting on "<0x839c4b90>"
As I mentioned before, the regression was hardly introduced by javacore, since there are almost no commits in the trunk for months in this module. BTW what are those "Timeout waitFinished compatibility processors"?
incomplete ? have tried it by yourself ?
The "Timeout waitFinished compatibility" very likely means that someone is waiting for FolderLookup on top of /Services/ to finish. The FolderLookup cannot finish, as it is blocked at "Folder recognizer" daemon prio=10 tid=0x08d37000 nid=0x2c67 in Object.wait() [0xb3ebf000..0xb3ec01b0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x82d5d170> (a org.openide.loaders.DataObjectPool) at java.lang.Object.wait(Object.java:485) at org.openide.loaders.DataObjectPool.enterRecognition(:279) - locked <0x82d5d170> (a org.openide.loaders.DataObjectPool) because the Java module decided to query the lookup from inside the createFromTemplate method: at org.nb.api.java.queries.SourceForBinaryQuery.findSourceRoots(:67) at org.nb.m.jc.cp.FilterClassPathImplementation.createResources(:121) I'll keep investigating, but as the IDE "wake-ups" it is hardly p1, is it not?
Yarda, as I've already said in one issue, the priority doesn't matter if you fix this issue as soon as possible (for this issue - now). Just in case you still want an answer on your question: I think it's P1 : - it's regression in "functionality" once could easy come to the decision it doesn't work - regression in performance (I don't think we can say "it works", because if it takes 2-3 minutes on my notebook, it will take ages on slowest machine as well I guess ...)
At the same time, when this bug appeared, also testOrderInAtomicAction started to fail. I do believe these two failures have the same reason. Thus making duplicate and I am working on the fix for issue 82459. *** This issue has been marked as a duplicate of 82459 ***
;)
*** Issue 82459 has been marked as a duplicate of this issue. ***
*** This issue has been marked as a duplicate of 82459 ***
verified duplicate .... in despite of : - this (issue 82454) had been reported before you reported (issue 82459) - this is issue with higher priority - this is bug in functionality, your bug is about failed tests So, in the future I would kidly ask at least to : - rise the priority - update depends on - add appropriate keywords - add appropriate mailing lists to CCs I would understand if somebody from the community does something like this, but I really don't understand if it's done by member of NB Development team.
I am sorry for not being able to understand your logic. This issue is caused by issue 82459. That is the root cause of the problem, the problem with form is just a side affect. I am not fully certain what you really want from me, but I can promise that in future I am going to close less descriptive and less well described issues as duplicates of the more detailed ones, especially if they are going to be automatically reproducible, like issue 82459.
release60-m2: http://openide.netbeans.org/source/browse/openide/fs/src/org/openide/filesystems/FileObject.java?r1=1.15&r2=1.15.2.1 http://openide.netbeans.org/source/browse/openide/fs/test/unit/src/org/openide/filesystems/FileObjectTestHid.java?r1=1.11&r2=1.11.2.1 http://openide.netbeans.org/source/browse/openide/loaders/src/org/openide/loaders/FolderLookup.java?r1=1.18&r2=1.18.2.1 http://openide.netbeans.org/source/browse/openide/masterfs/src/org/netbeans/modules/masterfs/Delegate.java?r1=1.23&r2=1.23.2.1