| New workspaces being persistently corrupted [message #1715055] |
Wed, 18 November 2015 16:13  |
Eclipse User |
|
|
|
I'm running Mars.1 on Ubuntu14.04 in a VM, hosted on CentOS7.1.
I've had a workspace on the host CentOS7.1 box for quite a while, working reasonably well. Almost all of the projects in the workspace are imported from my "git" tree (not copied), including several associated projects for an Eclipse plugin project I'm working on.
I've set up a virtualbox VM running Ubuntu 14.04, and I installed the same version of Eclipse. I have a shared folder that gives me full access to the same "git" tree on the host. In that instance, I did the same project import and eventually got a mostly clean workspace (one red X in a test project with a missing parent POM).
I used these two setups so that I could remotely debug the Eclipse plugin without locking up the GUI. This was working fine.
Then, a couple of days ago, after restarting my box for no particular reason, when Eclipse in the VM came up, the project/package explorer came up blank (except for my working set labels), not showing any projects, and the editor view just had an error like: Cannot determine URI for '/com.cisco.yangide.editor/src/com/cisco/yangide/editor/editors/YangAutoIndentStrategy.java'.
Note that I posted a similar question about this yesterday (https://www.eclipse.org/forums/index.php/m/1714931/#msg_1714931), but I have additional details, and I think a fresh post might be better.
I struggled with this for a day or so, even with help from "nitind" from #eclipse. I concluded that I would just create another workspace and redo the import and move on. This worked fine again for a day or so. This morning the same error happened again.
At this point I realized I could get more information about what's happening here by stepping through the Eclipse platform code that was throwing the exception. I had set up the VM so I could step through plugin code in a test instance, it was easy to set up the main instance on the VM with the "Xdebug" params so I could make the same remote connection from the host.
Here's some of the stacktrace where the exception occurs:
at org.eclipse.core.internal.filebuffers.ResourceFileBuffer.create(ResourceFileBuffer.java:238)
at org.eclipse.core.internal.filebuffers.TextFileBufferManager.connect(TextFileBufferManager.java:112)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.createFileInfo(TextFileDocumentProvider.java:559)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createFileInfo(CompilationUnitDocumentProvider.java:980)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.connect(TextFileDocumentProvider.java:478)
I stepped further into "project.exists()", and that led me to "org.eclipse.core.internal.resources.Workspace.getResourceInfo(IPath, boolean, boolean)". The key thing I noticed here is that the call to "!tree.includes(path)" was TRUE, which causes this method to return null.
I would really appreciate any (reasonable) additional requests for information, or ideas for how to resolve this.
I suppose I could create ANOTHER workspace and redo the setup, and relatively quickly set up the same debugging scenario, and try to step through the same code and see what's different, but I'm not really certain what I might make of those differences even if I see them.
|
|
|
| Re: New workspaces being persistently corrupted [message #1715286 is a reply to message #1715055] |
Fri, 20 November 2015 19:02  |
| Eclipse User |
|
|
|
Just now I hit this again. This is now my third corrupted workspace in a row. The workspace on the "host" is still working perfectly fine. It's only the workspace on the guest/vm that is giving me continual headaches.
When I created the second workspace, I selected the options to copy settings and layout. When I created the third one, I did not select those options. That at least eliminates that from a possible cause.
I'm now going to create a fourth workspace. The only variable I can see to vary this time is whether I copy files into the workspace on import. I guess I'm going to select that. This will be a very inconvenient choice moving forward, as I'll either have to manually sync changes over, or simply delete the projects and reimport them each time I want to debug new changes.
|
|
|
Powered by
FUDForum. Page generated in 0.03651 seconds
Home