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.

Bug 82454 - IDE frozen when you create JFrame
Summary: IDE frozen when you create JFrame
Status: CLOSED DUPLICATE of bug 82459
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: PERFORMANCE, REGRESSION
Depends on:
Blocks: 82041
  Show dependency tree
 
Reported: 2006-08-11 08:37 UTC by Marian Mirilovic
Modified: 2008-12-22 21:47 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
thread-dump (23.62 KB, text/plain)
2006-08-11 08:39 UTC, Marian Mirilovic
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Mirilovic 2006-08-11 08:37:40 UTC
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)
Comment 1 Marian Mirilovic 2006-08-11 08:39:29 UTC
Created attachment 32806 [details]
thread-dump
Comment 2 Marian Mirilovic 2006-08-11 08:40:44 UTC
reassigne to java / javacore
Comment 3 Marian Mirilovic 2006-08-11 08:43:07 UTC
Ups it isn't frozen, it just finished (after ~ 2-3 minitues on TM 8104/2GHz/1GB RAM)
Comment 4 Jana Maleckova 2006-08-11 09:37:32 UTC
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.
Comment 5 Marian Mirilovic 2006-08-11 09:47:12 UTC
I've been told to write here that it works fine with NB 5.5 (200608110000)
Comment 6 Jan Becicka 2006-08-11 11:00:13 UTC
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.
Comment 7 Tomas Zezula 2006-08-11 11:35:37 UTC
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.
Comment 8 Tomas Zezula 2006-08-11 11:53:53 UTC
I am also concerned with the number of "Timeout waitFinished compatibility
processor" threads which are waiting on "<0x839c4b90>"
Comment 9 Jan Becicka 2006-08-11 12:24:02 UTC
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"?
Comment 10 Marian Mirilovic 2006-08-11 12:38:00 UTC
incomplete ? have tried it by yourself ?
Comment 11 Jaroslav Tulach 2006-08-11 13:43:10 UTC
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?
Comment 12 Marian Mirilovic 2006-08-11 13:55:15 UTC
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 ...)
Comment 13 Jaroslav Tulach 2006-08-11 14:42:23 UTC
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 ***
Comment 14 Marian Mirilovic 2006-08-11 15:01:41 UTC
;)
Comment 15 Marian Mirilovic 2006-08-11 15:02:00 UTC
*** Issue 82459 has been marked as a duplicate of this issue. ***
Comment 16 Jaroslav Tulach 2006-08-11 16:19:02 UTC

*** This issue has been marked as a duplicate of 82459 ***
Comment 17 Marian Mirilovic 2006-08-11 16:49:00 UTC
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.
Comment 18 Jaroslav Tulach 2006-08-11 20:23:32 UTC
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.