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 69932 - Delete Project dialog not closed
Summary: Delete Project dialog not closed
Status: VERIFIED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords: RANDOM
Depends on:
Blocks:
 
Reported: 2005-12-06 11:00 UTC by Jiri Skrivanek
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread dump (23.62 KB, text/plain)
2005-12-06 11:02 UTC, Jiri Skrivanek
Details
Screen shot (101.52 KB, image/gif)
2005-12-06 11:04 UTC, Jiri Skrivanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2005-12-06 11:00:29 UTC
I've got into situation when Delete Project dialog was opened at 50% and it
wasn't never closed. It was probably caused by the fact that classpath scanning
was started at the same time. I hope thread dump and screen shot will be helpful
because I can't reproduce it anymore. I didn't do anything special. Just create
several java projects and then delete one of them.

Build 20051206-0733, WindowsXP, JDK1.5.0_05.
Comment 1 Jiri Skrivanek 2005-12-06 11:02:06 UTC
Created attachment 27583 [details]
Thread dump
Comment 2 Jiri Skrivanek 2005-12-06 11:04:05 UTC
Created attachment 27584 [details]
Screen shot
Comment 3 Jan Lahoda 2005-12-06 12:57:50 UTC
The dialog was not closed after the classpath scanning finished? Anyway, there
is probably nothing that can be done in projects, the delete process is not
finished and waits for a java's mutex, so the dialog cannot be closed.
Comment 4 Jiri Skrivanek 2005-12-06 13:03:49 UTC
> The dialog was not closed after the classpath scanning finished?

I don't understand this question. From screen shot it seems classpath scanning
started when the dialog was open.
Comment 5 Jan Lahoda 2005-12-06 13:17:50 UTC
Well, the process of project delete is blocked by the classpath scanning, but
once the scanning finishes the project delete should finish and the dialog
should be closed. Does this happen?

(BTW: I neither know why the scan started nor why the transaction is started
inside a file deleted listener, but it is not a problem of project delete.)
Comment 6 Jiri Skrivanek 2005-12-06 13:25:43 UTC
No, it stayed as shown in screen shot. If this is not your issue, please re-assign.
Comment 7 Jan Lahoda 2005-12-06 14:45:23 UTC
Aha, the situation is:
-the project delete starts.
-the classpath scanning starts.
-the classpath scanning never finishes.

I do not think this is problem in project delete: it simply deletes a file, but
this is blocked by a listener.

Passing to java/javacore for further evaluation.
Comment 8 Jan Becicka 2005-12-09 07:45:36 UTC
Really strange issue. In fact classpath scanning does not start. All threads are
waiting for ExclusiveMutex, but none holds it.
jskrivanek, did you use regular builds? Did you use any additional modules?
Comment 9 Pavel Flaska 2005-12-09 07:56:52 UTC
Issue #65815 shows the similar behaviour. Moreover, recently Petr Nejedly saw
this problem too. We have to think about some logging (to be able to see in log
who last entered the transaction). #65815 and Petr's was observable in build
with Collab installed. (There is nothing related with our transaction in collab,
but it can be better reproducible with this support.)
Comment 10 Jiri Skrivanek 2005-12-09 08:54:15 UTC
> jskrivanek, did you use regular builds? Did you use any additional modules?

It was continuous build 20051206-0733 (on WindowsXP, JDK1.5.0_05) started with
fresh userdir and only several java projects were created.

Comment 11 Jan Becicka 2006-10-26 16:27:54 UTC
Javacore module was replaced by Retouche infrastructure. This bug is not valid
in trunk any more.
Comment 12 Jiri Skrivanek 2006-10-27 07:45:35 UTC
Verified.
Comment 13 Quality Engineering 2007-09-20 09:55:15 UTC
Reorganization of java component