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.
|Summary:||Unnecessary external reload dialog|
|Component:||Data Systems||Assignee:||Jaroslav Tulach <jtulach>|
|Severity:||normal||CC:||anebuzelsky, apireviews, jbecicka, jglick, jlahoda, jstola, marfous, mmirilovic, monezz, musilt2, sj-nb, tim_sa, tzezula|
|Issue Type:||DEFECT||Exception Reporter:|
Project that exhibits the error.
Screenshot of Question Dialog Pop-up.
Full thread dump.
Making sure FileEvent.getTime() is the same as file timestamp after file change
Description MackSix 2011-10-11 03:17:14 UTC
Created attachment 111820 [details] Project that exhibits the error. Use attached project. 1) Open Project then open NewJFrame.java 2) Right click on Project and Choose "Rename". 3) Choose "Also Rename Project Folder". 4) Rename by adding some new number on the end. (e.g. JavaApplication13X) 5) Right click on Package. 6) Open NewJFrame.java file again. 7) Choose "Refactor>>Rename". 8) Change Package name. (e.g. javaapplication13X) 9) Choose "Apply Rename on Comments". 10) Click "Preview". 11) Click "Do Refactoring" on Refactor Window. A Question dialog box pops up indicating that NewJFrame.java was modified externally and asks if you want to reload it. See Attached Screenshot. The dialog box is locked on screen. Clicking the buttons or the red X will not close it and the NetBeans process must be killed with Task Manager. I have repeated this several times, but sometimes it works an other times it throws assertion and exception errors.
Comment 1 MackSix 2011-10-11 03:18:52 UTC
Created attachment 111821 [details] Screenshot of Question Dialog Pop-up. This dialog can not be closed and the NetBeans process must be killed.
Comment 2 MackSix 2011-10-11 03:21:26 UTC
Changing to P2 since it is required to Kill the process and restart NetBeans.
Comment 3 Jan Lahoda 2011-10-14 08:47:12 UTC
The deadlock appears to be in the form module (will attach a thread dump shortly). It is unclear to me why exactly the external reload is happening, but might be related to saving document on background outside the refactoring infrastructure.
Comment 5 Jan Stola 2011-10-15 09:22:41 UTC
> The deadlock appears to be in the form module In fact, GUI Builder just helps to disclose problem in CloneableEditorSupport or (in other words) GUI Builder runs into a deadlock-trap prepared by CloneableEditorSupport. The root of the problem seems to be the fact that CloneableEditorSupport displays the 'external modification' modal dialog while holding the document lock. This is deadlock-prone. Note that other events (from EventQueue) are processed by AWT-thread in this situation. For example, in the attached deadlock: RefactoringPanel: locks FormModel before document AWT-EventQueue-1: locks document before FormModel GUI Builder always takes FormModel lock before document-lock and as such cannot cause deadlock. Unfortunately, the locks are taken in the opposite order in AWT-thread because of the mentioned problem in CloneableEditorSupport.
Comment 6 MackSix 2011-10-29 08:02:51 UTC
I am getting this if I cut and paste a Java file from one package in a project to another package in the project. Sometimes it works and sometimes it is locked up and I have to kill the process.
Comment 7 Jan Stola 2011-11-09 08:03:11 UTC
*** Bug 204857 has been marked as a duplicate of this bug. ***
Comment 8 Jan Becicka 2011-11-09 14:42:02 UTC
*** Bug 204892 has been marked as a duplicate of this bug. ***
Comment 9 Tomas Danek 2011-11-09 14:48:33 UTC
FYI: for minimal test case see dupl. issue 204892 , 100% reproducible. making P1 since this usecase is really essential.
Comment 10 Jan Lahoda 2011-11-09 15:22:09 UTC
Even though I agree that the write lock is pretty ugly, I hardly see any way around it that wouldn't place us at risk of data loss. Consider e.g. IDE with autosave module, modified file and the same file modified externally. With some luck (if the autosave saves off-AWT), "Reload from disk" in the dialog will always read the original file in the current situation. If the document is not write-locked, and there is no further protection, the auto save may save the file, and then "Reload from disk" would actually load the same version that is in the editor. So, if at all possible, it would be better to resolve in some other way. In particular, it is not clear why this dialog appears in this context (i.e. why this dialog appears why the refactoring is in progress, when there is no real external change) - that should be investigated.
Comment 11 Jan Becicka 2011-11-09 15:26:31 UTC
BTW this is regression. We don't have such reports few weeks ago and I don't know about any recent change in refactoring which can cause this.
Comment 12 Jan Becicka 2011-11-10 09:43:05 UTC
This issue is not about deadlock, but about not necessary reload dialog which should not be invoked at all. This dialog is invoked specifically for form files.
Comment 13 Jan Becicka 2011-11-10 09:57:58 UTC
not only on form files, but even for textual files, as jlahoda discovered.
Comment 14 Jan Becicka 2011-11-10 10:41:23 UTC
Steps to reproduce: 1. Create a new empty file 2. Modify it and do not save 3. Move it in Explorer into different different folder 4. Reload dialog appears, although there is no external modification This issue is marked as P1, because it can lead to deadlock if form files are being refactored What happens. DataObject is modified and later moved into different folder. 1. Filesystems fire an event, which is not expected (isExpected() is false). This is probably wrong 2. DataEditorSupport refires this event as propertyChange "time" to CloneableEditorSupport. 3. CloneableEditorSupport gets change in timestamp which is newer than lastSavedTime and imo correctly tries to reload document. Interesting is, it worked correctly in 6.9, but it is broken since 7.0.
Comment 15 Jaroslav Tulach 2011-11-16 16:50:02 UTC
The problem is line firePropertyChange (PROP_TIME, null, new Date (fe.getTime())); in DataEditorSupport. It uses fe.getTime() which is then compared to fe.getFile().lastModified().getTime(). Usually the event is created after the file is saved and as such it is seem as newer. Which trigger's the dialog. The line has been introduced while fixing bug #155680 and could never be correct if the FileEvent was delivered after the save. However for some reason the event is not delivered in 6.9 at all - something else was probably broken.
Comment 16 Jaroslav Tulach 2011-11-16 16:55:48 UTC
Correction. The line was changed in the above indicated issue, but it is there since beginning of history at least since bug #32143.
Comment 17 Jaroslav Tulach 2011-11-21 10:37:54 UTC
Created attachment 113360 [details] Making sure FileEvent.getTime() is the same as file timestamp after file change
Comment 18 Jaroslav Tulach 2011-11-21 10:38:49 UTC
There is new constructor for FileEvent. I'd like to integrate tomorrow. Please approve.
Comment 19 rmatous 2011-11-21 10:49:48 UTC
I was asked to review the API change: adding new constructor. My opinion is that it make sense.
Comment 20 Martin Entlicher 2011-11-21 11:01:55 UTC
The diff at http://netbeans.org/bugzilla/attachment.cgi?id=113360&action=diff looks really terribly, it's not much readable. In "@param time ..." you have word "time" three times.
Comment 21 Jesse Glick 2011-11-21 13:37:06 UTC
(In reply to comment #20) > The diff at http://netbeans.org/bugzilla/attachment.cgi?id=113360&action=diff > looks really terribly, it's not much readable. See bug #205355 and click "View". Or use the "Bugzilla attachments" script .  http://wiki.netbeans.org/BrowserTools#Bugzilla_attachments
Comment 22 Jaroslav Tulach 2011-11-22 07:54:56 UTC
Comment 23 monezz 2011-11-22 09:35:51 UTC
*** Bug 205388 has been marked as a duplicate of this bug. ***
Comment 24 Jan Stola 2011-11-22 10:20:40 UTC
*** Bug 205332 has been marked as a duplicate of this bug. ***
Comment 25 Tomas Danek 2011-11-24 09:25:56 UTC
Unable to reproduce in custom core-main build -> verified in trunk Product Version: NetBeans IDE Dev (Build 20111124-a2921333b478) Java: 1.6.0_29; Java HotSpot(TM) 64-Bit Server VM 20.4-b02-402 System: Mac OS X version 10.7.2 running on x86_64; MacRoman; en_US (nb) User directory: /Users/tomas/.netbeans/dev Cache directory: /Users/tomas/.netbeans/dev/var/cache
Comment 26 Quality Engineering 2011-11-24 16:02:00 UTC
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/aa9820476791 User: Jaroslav Tulach <email@example.com> Log: #203477: Use timestamp of just written down file when creating FileEvent about the change
Comment 27 Jaroslav Tulach 2011-11-24 16:23:10 UTC
Martin Fousek claims that this changeset causes some of his tests to fail. Delaying integration to 7.1.
Comment 28 Martin Fousek 2011-11-25 08:49:32 UTC
(In reply to comment #27) > Martin Fousek claims that this changeset causes some of his tests to fail. > Delaying integration to 7.1. Right, only one in case of file change, in web.jsf module: SeveralXmlModelTest.testModelBeanCompletion But I'm still not able to figure out if it's fault of the test or not.
Comment 29 Martin Fousek 2011-11-25 11:13:13 UTC
Created attachment 113531 [details] AbstractDocumentModel-TD As far as I can say, it doesn't look to me like the test case issue. I doubted about timing troubles firstly but rewrite that or debugging (and wait for some specific actions in xml.xam model) didn't change anything. It looks to me that XML/XAM model doesn't get event about file change, strange. So than there is never fulfill condition inside AbstractModelFactory class: model.getAccess().dirtyIntervalMillis() > DELAY_DIRTY and the model is not resynced (so in the test is returned cached, not updated model and the test fails). Jardo, please could you take a look on that? I'm attaching stack trace of the event which doesn't happen to me by the test running with applied ergonomics#aa9820476791 changeset.
Comment 30 Martin Fousek 2011-11-25 13:43:15 UTC
Sorry Jardo, with the latest sources it's probably really timing issue as I was afraid about before. Not sure why it was not stopping to me on the breakpoint before but it could be caused by bad rebuild (doesn't suppose that it could be affected by another changset between #aa9820476791 and tip). Shortly no objections by me any more and sorry for the delay.
Comment 31 Jaroslav Tulach 2011-11-28 14:07:03 UTC
In release71 as e383199bb702
Comment 32 Quality Engineering 2011-11-29 08:46:27 UTC
Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/aa9820476791 User: Jaroslav Tulach <firstname.lastname@example.org> Log: #203477: Use timestamp of just written down file when creating FileEvent about the change
Comment 33 Sergey Petrov 2011-11-29 13:32:30 UTC
still have a lot of "read-only" and "modified" messages in entities form db and jpa controller from entities area, for me it's 100% reproducible today.
Comment 34 Sergey Petrov 2011-11-29 13:34:36 UTC
but, I'm not about reload dialog, I'm about save changes dialog and read only dialogs.
Comment 35 tim_sa 2011-11-30 12:18:58 UTC
*** Bug 205566 has been marked as a duplicate of this bug. ***
Comment 36 Tomas Danek 2011-12-01 15:51:01 UTC
verified in rc2