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 57855 - Lock command completion dialog can conflict with classpath scanner dialog
Summary: Lock command completion dialog can conflict with classpath scanner dialog
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscore (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Entlicher
Depends on:
Blocks: 57480
  Show dependency tree
Reported: 2005-04-13 22:49 UTC by Jesse Glick
Modified: 2005-09-05 10:14 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Deadlock (15.48 KB, text/plain)
2005-04-13 22:49 UTC, Jesse Glick
Screenshot (38.31 KB, image/png)
2005-04-13 22:51 UTC, Jesse Glick
Thread dump that leads to scanning classpath dialog. (7.72 KB, text/plain)
2005-04-14 13:34 UTC, Martin Entlicher
The temporary "deadlock" which occurs after the first file is processed. (24.13 KB, text/plain)
2005-04-14 20:26 UTC, Martin Entlicher
The hack to EventQueue to filter the deadlocking events. (3.15 KB, patch)
2005-04-14 20:42 UTC, Martin Entlicher
Details | Diff
A slightly modified partial solution through modification of EventQueue. (3.05 KB, patch)
2005-04-14 23:10 UTC, Martin Entlicher
Details | Diff
The working fix to this deadlock. (4.88 KB, patch)
2005-04-15 14:17 UTC, Martin Entlicher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-04-13 22:49:06 UTC
Dev build, Gnome + Metacity, JDK 1.5.

See issue #57480. Keep classpath scanning dialog *on* (i.e. do not use "ant
tryme"). Make a j2seproject in a CVS working directory. Watch all the metadata
files: project.{xml,properties}, build{,-impl}.xml, Check
out a fresh copy so that the files are all r/o. Configure the CVS working dir to
call EDIT locks but *not* prompt. Open project properties dialog and either
change the platform to a specific external JDK, or add some other j2seproject as
a subproject to the classpath. Close properties dialog.

Classpath scanning dialog appears, and so does a dialog saying that the EDIT
command completed (on some file, not sure which). However both dialogs are
modal, and you can't close either one. IDE has to be forcibly killed.
Comment 1 Jesse Glick 2005-04-13 22:49:43 UTC
Created attachment 21626 [details]
Comment 2 Jesse Glick 2005-04-13 22:51:21 UTC
Created attachment 21627 [details]
Comment 3 Jesse Glick 2005-04-13 22:52:40 UTC
Presumably VcsFileSystem.waitForCommand should not be waiting for a modal dialog
to be closed unless it can verify that there is no other modal dialog open that
would block it?
Comment 4 Martin Entlicher 2005-04-14 12:00:22 UTC
The classpath scanning dialog is opened after VcsFileSystem.waitForCommand()
opens the modal dialog. Therefore the classpath scanning dialog can check
whether there is not some modal dialog already opened (if it's possible?), and
wait after it's closed. Otherwise, every modal dialog in the IDE would have to
check whether there was not by chance some other modal dialog opened in between.

This particular case can be solved by auto-closing the VCS modal dialog, but I
do not think I can find out that another modal dialog was opened over me.

Looking into ProjectProperties.PP it looks that the scanning was triggered by
(external) modification of the file on which EDIT command was executed...
Comment 5 Martin Entlicher 2005-04-14 13:33:32 UTC
Actually Java is saving into files and refreshing codebase concurrently, as
apparent from the attached dump.
Comment 6 Martin Entlicher 2005-04-14 13:34:40 UTC
Created attachment 21648 [details]
Thread dump that leads to scanning classpath dialog.
Comment 7 Martin Entlicher 2005-04-14 14:00:38 UTC
That way Java will lock into itself until the save is not finished. IMHO it
would be better to sync that in Java. But as I looked into
J2SEProjectProperties, etc. it seems to be almost impossible to sync it there :-(

Comment 8 Martin Matula 2005-04-14 15:06:13 UTC
What is the purpose of the dialog? If it is just a progressbar, could it be
closed automatically once the action completes (no matter whether there is
another modal dialog or not)? Or could it be non-modal, so that once the
operation completes it will not block further processing?
Comment 9 Martin Entlicher 2005-04-14 15:44:34 UTC
It seems that it's not possible to fix this in VCS. Even when I close my modal
dialog, the AWT thread keeps waiting for the upper modal dialog. There is no way
how to get rid of once there is another dialog upon it.
This needs to be fixed in Java.
Comment 10 Martin Matula 2005-04-14 15:57:37 UTC
I don't see how we can help here. I guess this is more a project issue rather
than java issue (in case it cannot be fixed in VCS). Could the project files be
saved outside of the project mutex?
Or, Martin, could your dialog be non-modal?
Comment 11 Jesse Glick 2005-04-14 16:03:25 UTC
Get rid of the dialog, or at least make it nonmodal. Show some message in the
status line instead. Later, use Progress API in 4.2 or whenever it becomes
Comment 12 Martin Entlicher 2005-04-14 16:24:47 UTC
The dialog *must* be there, because otherwise one would not be able to cancel
the command if something goes wrong (so we will have the deadlock anyway if the
command runs forever).

Running a command in AWT and waiting for it (in AWT) is not not nice by itself
and looks like a bug somewhere... This would lead to deadlock immediately in
older releases.

So the only thing that seems to work is to make the dialog non-modal (I've
missed that comment from mmatula, because Issuezilla do not warn you any more
when the issue is out-of-date!)

So testing the change of modality...
Comment 13 Jesse Glick 2005-04-14 16:49:49 UTC
"Running a command in AWT and waiting for it (in AWT) is not not nice by itself
and looks like a bug somewhere..." - it is vcscore which runs a command and
waits for it indefinitely. Clients of the Filesystems API use the EQ routinely.
Comment 14 Martin Entlicher 2005-04-14 17:02:13 UTC
Sorry, but it's not possible.
When I make the dialog non-modal, this particular case works, but the dialog as
such is not usable.
When I e.g. add a field to a read-only Java file, when the dialog is non-modal
the IDE looks dead until the command finish. The dialog can not even pait
itself. It *must* be modal so that AWT can handle events.

I do not thing this is fixable on VCS side, sorry.
Comment 15 Martin Entlicher 2005-04-14 17:08:22 UTC
> it is vcscore which runs a command and waits for it indefinitely. Clients of the
> Filesystems API use the EQ routinely.
Yes, but when VFS.lock() or UQE.confirm() method is called in AWT, VCS can not
do anything about it. It *must* somehow call the command synchronously and wait
for it, because after lock() or confirm() finishes, the file must be already
Comment 16 Jesse Glick 2005-04-14 17:27:58 UTC
Then I would recommend requesting a waiver for 4.1, on the grounds that there
are two workarounds available and no fix is forthcoming, and maybe removing
support for pessimistic locks completely in 4.2.

Dafe, any insights on how different modules should manage clashing modal dialogs?
Comment 17 David Simonek 2005-04-14 17:42:48 UTC
Eeee, no idea for now...
Comment 18 Martin Entlicher 2005-04-14 20:24:47 UTC
I even tried to hack into the EventQueue and postpone the display of the second
modal dialog. After I've figured out which events should be ignored and which
should be passed on, this seems to work. At least for the first file, then it
temporarily deadlocks, because it creates two AWT threads.
But the deadlock is only temporary (if the command finishes) so it can be
considered as a partial solution. :-)
Comment 19 Martin Entlicher 2005-04-14 20:26:12 UTC
Created attachment 21659 [details]
The temporary "deadlock" which occurs after the first file is processed.
Comment 20 Martin Matula 2005-04-14 20:31:12 UTC
I still don't see why you keep assigning this to java. This needs to be fixed
either in VCS (to get rid of the dialog) or in projects - to not do this
expensive action in EQ, or under the projects mutex. Reassigning back to VCS.
Comment 21 Martin Entlicher 2005-04-14 20:42:00 UTC
Created attachment 21660 [details]
The hack to EventQueue to filter the deadlocking events.
Comment 22 Martin Entlicher 2005-04-14 20:49:54 UTC
It seems that all I can do it the attached modification to EventQueue. This
postpones the second classpath scanning dialog after mine is closed.
But it creates the attached temporary deadlock, that should be fixed in....
(projects? or Java?)
We need to have the second "AWT-EventQueue-1" freed up so that processing can
continue in the original "AWT-EventQueue-1" ;-)

I will try to figure out why
got into the second AWT event queue...
Comment 23 Jesse Glick 2005-04-14 21:02:27 UTC
The only problem I see in javacore is that it pops up a modal dialog
asynchronously (not in direct response to a user action), which is never a good
idea, but we already know that is not about to be fixed for 4.1.

I don't understand the last patch at all, but if it works, OK...
Comment 24 Jesse Glick 2005-04-14 21:21:12 UTC
Would it help for ant/project's UserQuestionHandler to wrap the retry block
(after the dialog is confirmed) in RequestProcessor? Easy fix if that is all it
takes. Not sure what other modules might still suffer from a similar bug, though.
Comment 25 Martin Entlicher 2005-04-14 23:04:02 UTC
O.K. so finally I've came to conclusion that it's really not possible to fully
fix this on VCS side.

I can put there the attached patch of EventQueue, but it might cause unexpected
behavior. The problem is that it creates a new EventDispatchThread and stops the
original one. (This was sort of unexpected to me, I thought that the original
will resume after the new one will finish.) Therefore there is created a new
dispatching thread, the old is left to die.
This makes clear why we can not solve the "temporary" deadlock attached here.
The original AWT event queue is not the dispatching thread any more, but holds
the write Mutex.

> Would it help for ant/project's UserQuestionHandler to wrap the retry block
> (after the dialog is confirmed) in RequestProcessor?
Not really sure what do you mean, but it would not solve the problem described
here - "Configure the CVS working dir to call EDIT locks but *not* prompt."
In this case no UserQuestionException is thrown.
The configuration *with* UQE worked fine for me (without deadlocks).
Comment 26 Martin Entlicher 2005-04-14 23:10:05 UTC
Created attachment 21661 [details]
A slightly modified partial solution through modification of EventQueue.
Comment 27 Martin Entlicher 2005-04-14 23:14:53 UTC
So moving to projects to evaluate and possibly resolve the remaining deadlock.

The behavior seems to be better, because the IDE resumes after some time. But it
looks frozen till the rest of files are not processed.

FYI: In PVCS the EDIT command can request an input from the user (e.g. to
confirm that a second lock will be applied). In this case we *need* to have a
free dispatching thread. Otherwise the command will never finish.
Comment 28 Jesse Glick 2005-04-14 23:28:01 UTC
I don't see anything to be done about the remaining temporary deadlock.

Put this fix in if you want, but it looks dangerous to me; I would recommend
just waiving the bug.
Comment 29 Milan Kubec 2005-04-15 09:27:29 UTC
Please, ask for waiver if it's not going to be fixed in release41. Thanks.
Comment 30 Martin Entlicher 2005-04-15 10:41:53 UTC
The fix by modification of the EventQueue is really too dangerous. I've found
that it breaks other things that works now (e.g. when someone add a method to
read-only Java file through context menu). Therefore I will not put that patch
into trunk.

I do not see a way how this can be fixed in VCS, if we should keep the contract
that after lock() call the file is writable, we have no option here.
Comment 31 Martin Entlicher 2005-04-15 10:44:15 UTC
:-) Even though I made *reload*, it moved the issue back to projects.

It will have to be discussed how to solve this in the future (see issue #57839).
Comment 32 Martin Entlicher 2005-04-15 14:15:50 UTC
This was sort of challenge for me, to try to fix something that is almost
impossible. ;-)

I have a working fix now. It's similar to the previous hack of EventQueue, but
it operates on the existing EventQueue rather then creating a new one. It
assures that while our dialog is opened, only selected events gets processed.

I do not consider it as a solution of the original problem, but just as a fix of
deadlocks of this kind. The original problem must be solved together with issue
Comment 33 Martin Entlicher 2005-04-15 14:17:04 UTC
Created attachment 21674 [details]
The working fix to this deadlock.
Comment 34 Martin Entlicher 2005-04-15 14:23:38 UTC
I've put the fix into trunk so that it can be tested.
The behavior is not great (the dialogs deserve some improvement), but it does
not deadlock:

new revision: 1.2; previous revision: 1.1
Comment 35 Martin Entlicher 2005-04-15 14:41:19 UTC
The fix is potentially dangerous, therefore I think that it should not go into
release41 without proper testing.
It can be considered for hotfixes if it proves to work fine...
Comment 36 Jesse Glick 2005-04-15 16:15:55 UTC
I agree this would best be waived for 4.1, at least until it is more thoroughly
studied and tested.
Comment 37 arseniy 2005-04-19 12:48:46 UTC
No objections to the waiver request for 4.1 ==> approved