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 | ||
|---|---|---|---|
| Product: | platform | Reporter: | MackSix |
| Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | anebuzelsky, apireviews, jbecicka, jglick, jlahoda, jstola, marfous, mmirilovic, monezz, musilt2, sj-nb, tim_sa, tzezula |
| Priority: | P1 | Keywords: | API_REVIEW_FAST |
| Version: | 7.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
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 AbstractDocumentModel-TD |
||
Created attachment 111821 [details]
Screenshot of Question Dialog Pop-up.
This dialog can not be closed and the NetBeans process must be killed.
Changing to P2 since it is required to Kill the process and restart NetBeans. 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. Created attachment 112043 [details]
Full thread dump.
> 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.
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. *** Bug 204857 has been marked as a duplicate of this bug. *** *** Bug 204892 has been marked as a duplicate of this bug. *** FYI: for minimal test case see dupl. issue 204892 , 100% reproducible. making P1 since this usecase is really essential. 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. 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. 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. not only on form files, but even for textual files, as jlahoda discovered. 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. 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. Correction. The line was changed in the above indicated issue, but it is there since beginning of history at least since bug #32143. Created attachment 113360 [details]
Making sure FileEvent.getTime() is the same as file timestamp after file change
There is new constructor for FileEvent. I'd like to integrate tomorrow. Please approve. I was asked to review the API change: adding new constructor. My opinion is that it make sense. 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. (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 [1]. [1] http://wiki.netbeans.org/BrowserTools#Bugzilla_attachments ergonomics#aa9820476791 *** Bug 205388 has been marked as a duplicate of this bug. *** *** Bug 205332 has been marked as a duplicate of this bug. *** 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 Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/aa9820476791 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #203477: Use timestamp of just written down file when creating FileEvent about the change Martin Fousek claims that this changeset causes some of his tests to fail. Delaying integration to 7.1. (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. 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.
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. In release71 as e383199bb702 Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/aa9820476791 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #203477: Use timestamp of just written down file when creating FileEvent about the change 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. but, I'm not about reload dialog, I'm about save changes dialog and read only dialogs. *** Bug 205566 has been marked as a duplicate of this bug. *** verified in rc2 |
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.