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.
[dev-20040120, Sun JDK 1.4.2_01] I experimented with debugger breakpoints persistance during project switching. Started with the Default project, added a couple of breakpoints to one of the example files. Then I opened a new project, mounted a local filesystem and added a couple of breakpoints to a file. Then I switched back to the Default project and got the o.openide.filesystem.FileSystemInvalidException (see the attachement). Both Projects and Window System can be found in the stacktrace, feel free to reassign if appropriate.
Created attachment 12998 [details] Exception stack trace
Passing to Marek, to consider whether there is some persistence problem. But is needed to say that an appropriate exception message is missing, what file is invalid?
I wish I knew. I hoped you would tell me. I've attached all I got.
It is group properties file. Window system configuration is saved when project is switched. However I have no idea why this could happen. I will try to reoproduce on Win XP. Is there any way how to reproduce it?
I tried dev build 200401201900, JDK 1.4.2_03 on Win XP. I have Default and P1 projects. Both have sampledir from userdir mounted. One different java source mounted in both projects and few break points defined. I tried to switch between those 2 projects many times. No exception.
I can reproduce it easily with one of the projects I've created. Don't know if I can replicate it from scratch. Feel free to stop by and I'll show you.
*** Issue 39173 has been marked as a duplicate of this issue. ***
*** Issue 39382 has been marked as a duplicate of this issue. ***
Taking over this issue for Marek.
Is anybody able to reproduce it somehow? Tim problem is: 1.I was not able to reproduce it. I switched project on Win XP and I was not able to get into this state. It looks like FS gets broken and then it is broken ie. exception is fired at every further project switch. 2.It is specific to windows. (At least all reports so far are from Win NT or Win XP.) From exception call stack it looks like FS where winsys tries to save its config data is broken somehow. (Data are stored to local FS into project layer Windows2Local folder.) If it is like that I suggest to lower priority to P3 to keep tracking it further.
I've seen it several times and probably can reproduce it in a couple of attempts. After that it's reliably reproducible until the IDE is restarted. I'll let you know when I get there.
Ok, got it. Feel free to stop by. :-)
I reproduced this easily, after doing the following: - Create project proj1 and some files in it - Create project proj2 and some files in it - With proj2 open, open Tools | Options - Change default compiler type to Jikes & execution to internal - Changed some other random settings: - Deleted the help menu - Moved a bunch of random things like autoupdate types into the project menu via the options UI (why on *earth* would someone want to associate an update center with a project????) [next couple steps probably irrelevant, but it's what I did] - Open Project Manager, select proj1. - Click Save As (save *what* as? This UI needs help), and save (I think...) proj1 as proj1saveas - Open proj1saveas [probably could have just reopened proj1 and skipped the Save As step] FSIE occurs quite reliably, probably only if some options have been customized specific to the project layer. My guess is it's some threading or order of operations issue - some settings are trying to save state info about a filesystem that the project action has already unmounted. I'll add some logging into PSupport and try to figure out what exactly is going wrong. Note that this issue may just get a hotfix that suppresses the dialog - build system in promo D will fix this for good, so it's not worth investing huge amounts of time in.
Created attachment 13214 [details] ide.log with full logging enabled and FSIE reproduced
One interesting thing: I added logging to SystemFileSystem.notifyMigration, to log whenever a file moves from one layer to another. I see a log message when I change any setting that is projectized, EXCEPT changes on the Java Sources node. For these, the UI updates to show that the sources are now stored in the project, but there is no notification that its settings file actually changed layers. It seems to be setting Default Debugger to Do Not Debug that triggers getting the FSIE on project change. I wonder if the Java module is doing something strange with its settings, and these never get stored with the project (but the project saving infrastructure sees them there and tries to save them).
Created attachment 13215 [details] Similar log, but also with core projects & system filesystem logging
Note that in the newly attached log, the order of operations appears correct - there is no change in the SFS before the winsys stores it's data (try to ignore the 879 SAXParseExceptions due to issue 39191).
FYI, I'm reproducing the problem on my mac - doesn't seem windows specific. A possible culprit is GroupParser line 453, which calls getFileObject(), then checks it for null (it shouldn't be), but doesn't check isValid() to see if it exists. BUT...I added some logging with a check of isValid(), and it returns true. One question is if we are talking to the right filesystem here. Note that the *Java* module goes and changes a setting on the Debugger module. This seems to have the side effect of dragging the Debugger's window system configuration into the project layer (even though no debugger windows have been touched), and this is what fails to be saved. Also, as noted earlier, changing the debugger setting on the Java Sources node does *not* cause anything to actually switch layers in the SFS. So nothing is actually changed until the project is saved. The failure happens when we try to write debugger settings to the project layer. Are we really talking to the project layer here, or are we trying to write into the Debugger's XML layer (which should fail)?
Hmm, also may be some bug in the layered filesystem? I added more logging - when the file to write to is fetched, I log the result of getFileSystem(). That works fine. But it appears that the lead filesystem when the FileObject was created was null. Maybe I can get Jarda to take a look at this with me - or Radek, perhaps you have an idea?
I've got it too (Sol 8)
Hmm, it seems that large numbers of fileobjects are created in this state - I added logging to AbstractFileObject, and on project switch, there are quite a few stack traces like: Null leader for output.wstcgrp filesystem is SystemFileSystem[org.netbeans.core.projects.SystemFileSystem@83f762] Default System Parent is Windows2Local/Groups/execution java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1082) at org.openide.filesystems.MultiFileObject.<init>(MultiFileObject.java:80) at org.openide.filesystems.MultiFileObject.createFile(MultiFileObject.java:393) at org.openide.filesystems.AbstractFolder.getChild(Unknown Source) at org.openide.filesystems.AbstractFolder.refreshFolder(Unknown Source) at org.openide.filesystems.AbstractFolder.refresh(Unknown Source) at org.openide.filesystems.AbstractFolder.refresh(Unknown Source) at org.openide.filesystems.MultiFileObject.refresh(MultiFileObject.java:380) at org.openide.filesystems.AbstractFolder.refresh(Unknown Source) at org.openide.filesystems.MultiFileObject.refresh(MultiFileObject.java:1180) at org.openide.filesystems.MultiFileObject.updateAllAfterSetDelegates(MultiFileObject.java: 203) at org.openide.filesystems.MultiFileSystem.setDelegates(Unknown Source) at org.netbeans.core.projects.SystemFileSystem.setLayers(SystemFileSystem.java:117) at org.netbeans.core.projects.SessionManager$1.run(SessionManager.java:128) at org.openide.filesystems.EventControl.runAtomicAction(Unknown Source) at org.openide.filesystems.FileSystem.runAtomicAction(Unknown Source) at org.netbeans.core.projects.SessionManager.setProjectLayer(SessionManager.java: 126) at org.netbeans.modules.projects.PSupport.projectOpen(PSupport.java:262) at org.netbeans.core.deprecated.NbProjectOperation.setProject(NbProjectOperation.java:136) at org.netbeans.core.deprecated.NbProjectOperation.setOpeningProject(NbProjectOperation.j ava:179) at org.netbeans.core.deprecated.NbProjectOperation.load(NbProjectOperation.java: 166) at org.netbeans.modules.projects.PSupport$2.run(PSupport.java:190) at org.openide.util.Task.run(Unknown Source) at org.openide.util.RequestProcessor$Task.run(Unknown Source) at org.openide.util.RequestProcessor$Processor.run(Unknown Source) Writing the rest of the settings doesn't fail, so what is special about the debugger settings in this situation?
Let me correct myself: Something *is* migrated to the user layer when you change the default debugger in java sources: SystemFileSystem.notifyMigration: Services AFAIK, though, this just means the services directory will now write to a directory on disk - probably changing any setting the first time will cause this.
Tommorow I'm ready to look at it. If you are fed up with it then just reassign to me.
Ask and thou shalt receive :-) Seriously, this one is making my brain hurt. Best avenues for exploration: - Does the debugger know it has settings in the layer? The root of the problem may be communication between the Java module and the debuggercore. - Why does changing a debugger setting get its windows, which have never been opened, moved to the project layer?
Created attachment 13247 [details] patch with possible fix
There is problem in MFS impl., that should be solved more radically, but I hasitate before 3.6. There is problem with updating after setDelegate on MFS (moreover complicated with GC). Attached patch is far from ideal, but could be sufficient and relatively safe. Please use attached patch and try to reproduce.
Created attachment 13248 [details] Sorry, the first one patch can't be compiled. USE THIS ONE.
Well, I think everyone is okay with a *temporary* patch to swallow the exception in Winsys, but there is a real bug here which needs to be fixed. So maybe put the hotfix in but leave the issue open at lower priority for a real fix later. Dafe? Honza?
Maybe I'm blind, but I don't see any exception swallowing in Radek's patch. IMO such nasty things as exception swallowing could be put only to branched 3.6, to be sure that it doesn't remain in trunk when buildsys is going to solve it. However I agree with applying Radek's patch, I didn't found it scary, although I don't understand the details.
This patch doesn't swallow any exeption. I think that it is OK for this issue. I mentioned that this patch is far from ideal, because setDelegates on MFS isn't tested, I can imagine a few other scenarios, I assume that events to FileChangeListeners may not be delivered reliably and also I felt a little blue after spending one day by solving this issue.
Can you please attach the binary version of the patch?
Created attachment 13275 [details] fs.jar with patch
I'm no longer able to reproduce the exception with the patch from 2004-02-05. I tried creating and opening many projects and everything seemed to work fine. I think it can be integrated into 3.6.
/cvs/openide/src/org/openide/filesystems/AbstractFolder.java new revision: 1.70; previous revision: 1.69 /cvs/openide/src/org/openide/filesystems/MultiFileObject.java new revision: 1.114; previous revision: 1.113
verified, doesn't happen anymore. And see jchalupa's last comment ;)
*** Issue 39951 has been marked as a duplicate of this issue. ***