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 136994 - "JavaSource.runCompileControlTask called under Document write lock" in RefactoringActionsProvider$NodeToFileObjectTask.run
Summary: "JavaSource.runCompileControlTask called under Document write lock" in Refact...
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: mslama
URL: http://konik-z2.czech.sun.com:8080/hu...
Keywords: RANDOM, TEST
Depends on:
Blocks:
 
Reported: 2008-06-11 14:29 UTC by Jesse Glick
Modified: 2008-12-22 11:17 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Stack trace (15.27 KB, text/html)
2008-06-11 14:30 UTC, Jesse Glick 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-06-11 14:29:24 UTC 
Seemingly random failure in C/V.
Comment 1 Jesse Glick 2008-06-11 14:30:29 UTC 
Created attachment 62662 [details]
Stack trace
Comment 2 Jan Becicka 2008-07-31 09:07:38 UTC 
It looks like some race condition. Refactoring module does not hold any lock on document. It is held by
CloneableEditorSupport listener.
Comment 3 Jan Lahoda 2008-08-01 00:09:40 UTC 
I am afraid I do not see anything that could be done in java.source to prevent this: JS.rUAT is really executed under
document write lock (atomic lock counts as a write lock), which is deadlock prone.

I would recommend to try this (in the order of (my) preference):
-is it really necessary to show dialog (about document reload, I presume) under the document atomic lock?
(CloneableEditorSupport.checkReload) I do not like this.
-not sure if this can really happen in practice to a user (an external modification of a modified document, which is
currently subject of a refactoring) - maybe we could investigate why this happens in the tests at all, fix the tests and
make this P4?
-try to offload the refactoring's work to a different thread (keeping the AWT thread empty, if it would be waiting, the
deadlock could still occur)
Comment 4 Jan Lahoda 2008-08-01 00:10:47 UTC 
Clarification: by "I do not like this" in the first item I mean: I do not like showing a dialog under document atomic lock.
Comment 5 mslama 2008-09-23 14:33:01 UTC 
It looks like problem with test to me. There are 2 dialogs in chain and it should not happen IMO. It is not clear to me
how refactoring module is invoked after reload dialog is closed. I would need to know what test is it and what it does
esp. if it selects Yes or No on reload dialog. CES property change listener on document uses SwingUtilities.invokeLater
to post reload dialog to AWT so it should not be chained with refactoring dialog at all. Lukas do you know who could
tell us more details about this test?
Comment 6 mslama 2008-09-25 14:56:36 UTC 
It looks like Refactoring dialog and then Reload dialog was shown, But test is not designed to handle Reload dialog so
Reload dialog stays opened and keeps its document lock. Jemmy is able to close Refactoring dialog and continue with
refactoring so result is failure. One solution would be to modify test to detect if Reload dialog is opened and close it
first to release document lock. I am closing it for now if this happens again we can try to modify test to handle Reload
dialog. (Another question is how it is possible document is modified externally but I do not know how to find out who is
doing that.)

This cannot happen under normal IDE usage because user is not able to close Refactoring dialog before Reload dialog is
closed.