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.
I'm using Clearcase, where files are read only till checked out. I was internationalizing a folder full of files, but forgot to check out the bundle. The wizard froze after the second screen (when it starts processing the files), and it froze the whole program. Instead, it should warn the user, and quit the wizard.
I cannot reproduce on local filesystem with readonly files. So I guess you are refering to virtual files created by NetBeans clearCase module. Do you? Please attach freeze thread dump.
I tried set some java and properties files to read-only, but I cann't reproduce the freeze. (only 1-3 seconds IDE repainted windows) I tested "Internationalize..." and "Internationalization Wizard" feature from menu. Could you please add some detailed description: IDE version - there is info about IDE in About dialog ( from main menu Help|About ), Java version, and detailed steps to reproduce this issue. Thanks
If this is not easy to reproduce, then maybe it should be closed. I was using a local filesystem also (the clearcase integration appears not to work for nb 3.5). IDE version: IDE/1 spec=3.38 impl=200302190100 Java 1.4.1_01 If you still want the freeze thread dump, let me know where to find it. Julian
Thread dump = Ctrl + Break pressed in console window while IDE seems to be frozen.
Created attachment 9551 [details] Thread dump after NB freezes
So it looks like deadlock at <049F6C78> lock. One possible solution is to use private lock in UndoRedo.Manager.addChangeListener as it can be subclassed and subclass shares the same lock.
Undo/Redo is core/editor subcat, I think
Created attachment 9604 [details] excerpt from the original log showing the two problematic threads
Created attachment 9605 [details] proposed patch
David it cannot work. You must get rid of synchronized (this) and replace it by synchronized(PRIVATE_LOCK) where private lock is a field declared as: private transient Object PRIVATE_LOCK = new Object();
(all this was written before Peter's previous comment - will reply to it separately) I attached simple patch which should hopefully prevent the problem. I agree with PetrK that problem is in synchronization of UndoRedo.Manager.addChangeListener() which seems to me not necessary. However the cause is in CloneableEditorSupport.revertUpcomingUndo() method. Peter Zavadsky could you please look at my last two attachments? The first one shows the problem and second is patch. What's your opinion on it? The CES.revertUpcomingUndo() was added by you recently. The problem is that thread A calls setUndoTask with new UndoTask and then it calls synchronized UndoRedo.addChangeListener(). However, the UndoTask which was set is immediatelly started (let say thread B) and it calls UndoRedo.undo() which is synchronized as well. The result is that A hold write lock on document and waits on B and B waits on write lock. Other possible way how to solve it would be to reorder calls in revertUpcomingUndo(): first UndoRedo.removeChangeListener(), then setUndoTask() and then UndoRedo.addChangeListener. This should prevent the problem as well because nobody could start UndoTask because there would be no listener. At the moment it seems to me that both these changes should be applied as they make sense to me, but would like to hear PeterZ's opinion. Should it be fixed for NB35? I do not know. I would like to ask QA to test some scenarios similar to Julian's one and then decide. From the Julian report it looks that it is always reproducible. How frequent this scenario is I do not know. From other comments in this issue it looks that it is not general problem of readonly files. The fixes I proposed are relatively isolated and should not have sideeffects. However I must admit that I do not understand why this problem happens (and source code is not clear to me either) and so the fix can solve the problem just partially.
PetrK: the problem happens only when list!=null so it should work I guess.
Right, but this way you can create two list instances, resulting in one listener getting discarded.
> Should it be fixed for NB35? I do not know. I would like to ask QA to > test some scenarios similar to Julian's one and then decide. I've tried it without success,but I haven't clearcase, I've tried it only with cvs and read-only files. > From the Julian report it looks that it is always reproducible. How frequent > this scenario is I do not know. From other comments in this issue it > looks that it is not general problem of readonly files. I don't reccomend fix this one for release35: - We cannot reproduce it, it's reported only by one user, it's reproducible only by the specific occurence, we will not be able verify fix, ...
Just a little note: The cause isn't in CES.revertUpComingUndo() method, but in UndoRedo class - even you are pointing out to that code. In this case it is a problem UndoRedo uses itself as a lock (which is exposed that way) for lazy init its listener list. And the same lock is used in CES/subclasses for other purposes. That's wrong. To the fix. Generally if some class uses synch blocks for its field, it should use some internal locks, not exposed ones. However in this case I would prefer remove the synch modifier at all and set the list field as final and initialize it directly at declaration. I guess the lazy init doesn't have a sense here.
Thanx. Will fix it once the trunk is buildable. Marking as P3.
Fixed in: Checking in src/org/openide/awt/UndoRedo.java new revision: 1.23; previous revision: 1.22
Fixed.