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.
Starting NB and the editor displays but with only 1 file instead of the 5 or 6 that I had open when I shutdown the system. A dialog box appeared with java.io.IOException appeared. The last time this happened I lost some of my projects as well as some of my filesystem settings in the project within which the problem appeared.
Created attachment 3940 [details] NetBeans ide.log
Problems with settings in windows system.
I see in the log java.lang.NullPointerException at org.netbeans.modules.debugger.support.actions.DebuggerWindowPerformer.getDebuggerWindow(DebuggerWindowPerformer.java:108) at org.netbeans.modules.debugger.support.nodes.DebuggerWindow.readExternal(DebuggerWindow.java:194) IMO this is a bug in the debuggercore module. Perhaps the window system is not robust enough to survive this failure. I am not sure though
Created attachment 3957 [details] clean log of java.io.IOException
Additional information: On another occurance of the problem I checked my settings and found; tools/options/building/compiler types besides the compilers listed, there were 25 lines that read; SAX Parser Sure does not sound like a debugger bug to me...
> Sure does not sound like a debugger bug to me... agreed. I just want to say that the other exceptions _may_ be caused by the NPE in the debuggercore module. And as I said before in any case the window system should be more robust in situations like this
Yes, and I have had debugger problems so the log has probably pointed you in a different direction from the description of this problem. That is why I added the clean log. I have had debugger errors but wrote them off to being caused by other things, such as my firewall.
As I am now getting this error everytime I start my project under NB I checked the folder .../system/projects/argo/system/windows/components and found 79 *.settings files....this can't be right, can it? Can someone tell me how I can prevent this error from happening everytime I load my project. If I delete all the files in that directory will NB rebuild the correct one (s)? I know that others on the user mailing list are having similar errors.
*** Issue 18975 has been marked as a duplicate of this issue. ***
Not reproducible => lowering priority to P3
I have fixed small problem in debbugger (NPE) related to this report (release33 branch). But I really belive that debugger is not the original source of it.
Lowering priority to original value and asking window system guys for further investigation.
Phil, you can safely delete all those subdirs {YOUR USERDIR}/system/projects/{YOUR PROJECT}/system/windows You'll lose all workspace layouts but nothing else (editor settings for example remain intact) Please take the 3.3.1-dev nightly build tomorrow and test if it works for you. I recommend to explicitly specify a different location for your userdir, just in case the dev build wants to eat your settings :-(. runide.exe -userdir c:\nbuser331 will do. For now I am closing this one as fixed. If the problem persists even with 3.3.1-dev, please reopen. Thanks
Problem happened again. I had 10 files open and when I tried to dismount a file system the unmount failed (probably because I had a file in the editor). When I reloaded NB I got warnings about the windows file setting being corrupted. Am attaching a clean log.
Created attachment 4018 [details] Clean log of file system settings corruption.
there are actually two separate issues: 1) you failed to unmount a filesystem having files opened in the editor should not cause the failure. This is the bug. I don't see any exceptions related to this. Is it reproducible? 2) Windows/Components/filesystems.settings is corrupted, at least the IDE thinks so. Please attach this file here. Or better zip your <userdir>/system/Projects and attach the zip file here. Thanks
Clearly it is problem of InstanceDataObject so I assign this issue to jpokorsky.
Phil can you zip your userdir (c:\nbuser331\system is enough) and attach to the bug please? Do you remember steps how to reproduce the bug? I would very appreciate them. Thanks
*** Issue 18814 has been marked as a duplicate of this issue. ***
<written by Phil> Hi; I'm sorry but I cleared out the windows directory just after I reopened the problem. I will try to reproduce the error and post the info. It has been very reproduceable up till now. I just have to open 10 or more files and then exit NB. When I restart the error happens. I have been able to work by making sure that I never open more than 8 files at any one time. There was no exception, just a box saying it was trying to unmount the filesystem (it had moving dots on it)...I don't remember what I answered . I actually didn't see this box until I was shutting down. </sent>
Strange! Phil, I've tried to reproduce steps you mentioned using more than 300 opened files on two platforms Solaris and w2k without any exception :(. It would be greate if you reproduce it again and attach your zipped system folder. I'll prepare a patch trying to solve the problem and dumping more debug details to ide.log
Created attachment 4049 [details] Here is the patch. Should be placed in {nb.userdir}/system/lib/patches
> Should be placed in {nb.userdir}/system/lib/patches WRONG. The location should be {IDEHOME}/lib/patches. Create the dir if it's not there and don't forget to delete it after finishing testing.
Here is more info from Phil > Phil Sager wrote: > > Here is the patch. Should be placed in {nb.userdir}/system/lib/patches > do you mean {nb.userdir}/lib/patches ??? Sorry it was my typo. You are right. > and do I have to unzip or do anything??? No no just place it there. > and so far I have not been able to reproduce the problem either, > hmmmm, the only thing I did since then is remove the old version of > NB3.3. I wonder if it was interacting somehow ... [;o] If you did not share same userdir then no.
*** Issue 19252 has been marked as a duplicate of this issue. ***
Phil it is not necessary to reproduce it again. After deep investigation I found out some .settings files of the window system are scheduled to write down when jvm shutting down. So me and window system guys are preparing a fix solving the problem. Thanks for your help.
The window system storing is synchronized with the ide session closing now. It also helps to solve performence issues (some TopComponents are stored too often). Fixed in the trunk: org/netbeans/core/windows/PersistenceManager.java, v1.23 org/openide/loaders/InstanceDataObject.java, v1.115 Jardo, Dafe can you review the code please?
patch verified.
Approved by QA.
Approved.
Fixed in the release33 branch: org/netbeans/core/windows/PersistenceManager.java, v1.20.4.7 org/openide/loaders/InstanceDataObject.java, v1.113.2.6 Phil, you can try today build (16 Jan) from http://www.netbeans.org/builds_archive_release33.html or wait for RC2.
*** Issue 17143 has been marked as a duplicate of this issue. ***
Resolved for 3.4.x or earlier, no new info since then -> closing.