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.
I am working on a project with some other users. We did conflicting changes to some of the project.xml files. When I restarted the IDE, I get a continuous steam of exceptions from o.n.m.apisupport.project.ModuleList.parseData(line 545). It is because the SAX parser is really upset about seeing the cvs conflict marker. Since the "conflicted" project was open in the IDE, I restarted the IDE with a new userdir. Then, I used the versioning manager to try to gain access to the files (so I could resolve the conflicts). One problem, though. a few seconds after the versioning explorer appeared, the SAME exception started to appear and froze the IDE (again). The "root" of the stack looks like it is in vcscore.VcsFileSystem.getSharableFiles (line 2261) So, I am off to vi.
If you have merge conflicts, you have to resolve them textually before you try to open the project. There is conflict resolution GUI in the IDE's VCS integration currently; it is generally best to use a text editor for this purpose. See issue #42686 for proposed XML validation of project.xml files (might or might not help in your case, hard to tell without details). Any exceptions in VcsFileSystem should be reported in vcscore/code; I don't know what they mean and I can't do anything about them, but they are probably fixable if you attach your log file (especially if you know how to reproduce). BTW giving a line number in a Java class in apisupport/project is not always useful since we change some of these sources every day. Usually need a stack trace plus a build number. *** This issue has been marked as a duplicate of 42686 ***
Created attachment 22600 [details] here is the stacktrace for you.
Closing an IDE hang bug as a duplicate of an enhancement is a very creative issue management system.
Yes, not quite the right duplicate marker; I forgot about the related issue #47288.
*** This issue has been marked as a duplicate of 47288 ***
Looks like the IOException was caught by SimpleFileOwnerQueryImplementation. (Not sure why "[catch]" was not marked there; possible bug in NbErrorManager?) But I doubt that would have caused an IDE hang, just exceptions. If there is a hang, (1) it might be a result of some other bug (possibly triggered by this one); (2) need a thread dump to diagnose it.
I mis-spoke. The IDE doesn't hang. The exception just keeps repeating in the console window, so the machine is so busy updating the console window with stack traces, that the IDE becomes non-responsive. Windows don't redraw, that sort of thing...
That would happen e.g. if you had a lot of NBM projects open.
I had a fresh clean userdir with NO open projects. Only two of the projects that were in the versioned filesystem/directory hierarchy had cvs conflict markers. The stack trace was continuous. I had to kill netbeans with a control-C. That is what prompted me to file this as a P2. If it had "done it once" for each broken project.xml file I would not have been so tweaked about it. Or kept persuing it after you closed it as a dup the first time.
Probably it *was* throwing an exception only once per call to SharabilityQuery.getSharability, but the VCS integration made this call lots and lots of times. (Just guessing here - have never seen it happen myself.) Currently ProjectManager does not cache exceptions, nor does ModuleList, since it is more likely to do harm than good - you might have a problem, fix it, and then expect things to work again without restarting the IDE. This design is however optimized for the case of a small number of significant calls to ProjectManager.findProject (e.g. the Open Project dialog); a query like SharabilityQuery is making a large number of calls to PM.fP but an error is hardly a big deal (it can be "swallowed" without causing serious problems). It would be possible to make SimpleFileOwnerQueryImplementation.getOwner *not* report IOException's it gets, which would help in your case (there would still be a lot of exceptions but at least you would not be slowed down by logging them), but conversely make debugging problems much more difficult in other cases. Longer-term, ModuleList would ideally skip over broken modules (reporting one error for each, the first time it is asked to scan a given root), but then also listen to changes in the metadata of all modules in its root, so that if you fixed one of the broken ones, all the related ones would quietly be updated to reflect its non-broken status (meaning changes in their classpaths, etc.). But this promises to be a bit complex to implement, and we have much higher priority things to deal with right now.
*** Issue 59814 has been marked as a duplicate of this issue. ***
ok, duplicate. v.