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.
This bug has happened to me several times over the past few months in dev builds. I cannot be sure when the first time was, and I have no clue how to reproduce it. The symptom is that modifications to a file stop being written to disk after some point. So I start making changes to some source file, saving periodically e.g. by running an Ant build. After a while I notice that the program is not picking up changes I make, the debugger jumps right over lines I have added as if they were comments, etc. When I check the file on disk using an external editor, it contains something that I saved half an hour ago, and none of my more recent changes. There is no indication in the IDE that anything is wrong: file modification boldfacing works normally, diff bars appear for additions, etc. Workaround (once I figure out what is happening) is to copy the contents of the buffer, paste into a scratch buffer of an external editor, close the IDE editor window, use the external editor to overwrite the file contents, and reopen the file in the IDE.
Happened to me again the other day, and again today. Something to do with reloading an externally modified file from disk.
I think it's https://netbeans.org/bugzilla/show_bug.cgi?id=191620#c46
If true, that would be a trigger condition; but even if that exception is fixed, the bug remains that exceptions thrown from certain parts of the code (of which there will inevitably be more) put the document into a broken state from which it is not trivially recovered. If things get that mangled, the editor impl perhaps needs to close the editor pane, write any outstanding document contents to some backup file, and discard the document.
Jesse, you are absolutely right. I think issue #191620 is a lucky case for editor team to try and find missed try { } finally { } block which leave editor in broken state. Btw, data lost is P1.
Editor team, https://netbeans.org/bugzilla/show_bug.cgi?id=191620#c46 contains 100% reproducible test case for IDE build: Product Version = NetBeans IDE Dev (Build 110209-dc1140292e0c) (#dc1140292e0c) throwing other exception could leave editor in broken state and cause data lost. Don't miss your chance to fix it :-)
Fortunately I have never lost data this way, just a lot of time trying to figure out why none of the fixes I make seem to be affecting the bug at hand, and why the debugger is stepping into comment lines! Once you realize this bug is active, you can Ctrl-A Ctrl-C, open the file in Emacs, paste in your fixed content, and restart NB. But if you were unfortunate enough to just close the editor window, you can lose whatever you recently changed.
(In reply to comment #6) > But if you were unfortunate enough to just close the > editor window, you can lose whatever you recently changed. That was my case :-(
Appears that openide.text/CloneableEditorSupport.reloadDocument is not really prepared that something can go wrong during the reload. To reproduce, place: if (true) throw new UnsupportedOperationException(); below: ERR.fine("clearDocument"); (currently line 1718). The most reliable solution might be to inform the user that something went wrong during the reload and close&reopen the window. I did a quick test, and it seems that this works (also possibly because the exception is not thrown outside the runAtomic innerclass). But I do not understand the inner workings of CES enough to foresee the consequences. Also not sure if this is the originally reported problem - no exception was mentioned, so there is possibly other way to mangle the CES' internal state (+undo listeners).
As Jan pointed out if some exception occurs in the mentioned section of the code it might get into the wrong state. I believe the exception that could possible come from that part of code were fixed. Also the probability that this happens is very low since it is only when doing reload of externally changed file. The last piece of the mosaic is that we really don't have anyone to carefully examine the problem and who knows platform/text code enough to be able to fix it. Unless there is someone willing to step up I am closing this as works for me.
(In reply to comment #9) > I believe the exception that could > possible come from that part of code were fixed. I _think_ I have seen this bug since that fix; not sure. And I certainly have encountered it in the past, well before the exception in #191620 was introduced. From what I understand, any of a wide variety of unrelated errors could trigger this problem - just as failure to close a stream in a finally block can cause an I/O handle leak as a result of any kind of error thrown while processing its contents. > the probability that this > happens is very low since it is only when doing reload of externally changed > file. To the contrary, this happens all the time. For example, some file is open in the editor that you have recently modified and committed, and from a shell you 'hg fetch' when there are also remote changes. After pulling, Hg will first update to the remote tip, causing a native file notification triggering a document reload in NB (see bug #194147 for discussion), then merge with your local changes, triggering another document reload. Regardless of whether you know how to reproduce the problem (besides the artificial step given in comment #8) or intend to fix it, P2 priority is appropriate for a bug that can cause data loss like this.
(In reply to comment #10) > Regardless of whether you know how to reproduce the problem (besides the > artificial step given in comment #8) or intend to fix it, P2 priority is > appropriate for a bug that can cause data loss like this. +1 !