Bugzilla – Full Text Bug Listing
| Summary: | Source not found | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Darin Wright <darin.eclipse> | ||||||||
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | cocoakevin, Darin_Swanson, dj.houghton, john.arthorne, rvprasad, szymaniak, Terry | ||||||||
| Version: | 3.1 | ||||||||||
| Target Milestone: | 3.1 RC4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Darin Wright
Created attachment 23540 [details]
Example workspace that causes the error
I tried to debug and found something weird in org.eclipse.debug.internal.core.sourcelookup.containers.ContainerSourceContaine r.findSourceElements(String) At line 121 in ContainerSourceContainer.java osFile="/home/venku/workspace/installations/eclipse/workspace/test/Test.java" canonicalPath="/workspace/installations/eclipse/workspace/test/Test.java" canonicalSegments="[workspace, installations, eclipse, workspace, test, Test.java]" workspacePath="workspace/installations/eclipse/workspace/test/Test.java" Subsequent invocation fRoot.findFilesForLocation(workspacePath) at line 121 returns an empty array as there is no such location as mentioned by workspacePath. On my Linux box I start eclispe with "eclipse -data /home/venku/workspace/eclipse" where "/home/venku/workspace" is a symbolic link ot "/workspace". So, canonicalPath.getDevice() should return the device on which "/" is hosted. Instead it returns null which I think is incorrect. Does source lookup work when the workspace in *not* in a location identified with a symbolic link? Created a symbolic link to my target workspace, launched the target using the linked workspace and found any launch in a project that is in my workspace directory could not find source. Did some debugging and found that we attempt to find the file using it's canonical path, but IWorkspaceRoot does not consider the canonical path when attempting to find the file. In this case project.getLocation() returns the linked location, which is different from the canonical path to the project. John, what is the story for launching with a symbolic link to your workspace? Is this a core bug or are we just trying to do something that is not supported? Also CC'ing DJ for comment. Just to clarify the steps so I can reproduce the problem...this is my set-up: - eclipse installed in /opt/eclipse/r31rc3 - workspace in /home/dj/target - symbolic link /home/dj/rtw -> /tmp/runtime-workbench - run Eclipse - create new Eclipse app with the -data pointing to ~/rtw - try to debug something with source in my workspace Which step am I missing? Does my original workspace have to be in a linked folder as well? I don't need to make any changes to my host. My set up is this: target workspace: /Users/kevinbarnes/Eclipse/runtime-workspace/ symbolic link: /Users/kevinbarnes/Eclipse/link-runtime-workspace -> /Users/kevinbarnes/Eclipse/runtime-workspace launch the target with -data /Users/kevinbarnes/Eclipse/link-runtime-workspace Create a Project in default location (ie inside the workspace) Create HelloWorld in that Java project Set a breakpoint in it and debug. Notes: I'm testing on a mac, but I suspect the behavior is the same on linux. I tried using ~/Eclipse/link-runtime-workspace, but it didn't work for me. Eclipse incorrectly considered it to be a relative path: "/Users/kevinbarnes/Eclipse/RC3/Eclipse.app/Contents/MacOS/~/Eclipse/link-runtime-workspace" I have a project that is not in the workspace (it's in /Users/kevinbarnes/Projects/junit3.8.1) and I can find source properly in it. Oh wait, I am now able to reproduce the problem with my setup in comment #6. If I create a simple java app and put a breakpoint in #main I don't get source. The problem is in FileSystemResourceManager#allPathsForLocation. Like Kevin mentions, the project location is not canonicalized so the #isPrefixOf check is returning false and we aren't getting any results added to our list. Canonicalizing the project location seems to fix the problem. Moving bug since it seems to be a problem in Platform/Resources. So this seems to be a problem when you are debugging and your target workspace is pointing to a linked folder. (*nix symbolic link, not Eclipse linked file) Darin, what are your thoughts on this for 3.1? In Core we are usually very conservative near the end of the release cycle since any changes we make will inevitably break someone upstream. This bug was since we enhanced source lookup to support case insensitive platforms and to support relative path names (in 3.1). Thus, our source lookup algorithm has changed, but the same scenario works on 3.0 (symbolicly linked folders). Thus, to support the new features, we have broken a previously working scenario. We could add a workaround into source lookup (revert to using IContainer.getFile(...) when we don't find the file using case insenstive, relative path support), but this means that relative path names won't work when folders are symbolically linked. In 3.0, it appears that the platform behaivor might have been slightly different (the workspace in 3.0 thinks its workspace is located at the "real" location, rather than the "linked" location). I think debug will need to do something to fix this, if the platform does not, as it represents a regression from 3.0. typo: "this platform bug was *revealed* since..." Ok, I'll have to run some tests to see if it is a regression at the platform level from 3.0. That being said, I feel very uncomfortable releasing code changes like this since this is the last week before we ship. If this is a regression, then we need to determine if its a stop-ship. (don't think it is though?) Created attachment 23573 [details]
potential work-around for 3.1
Potential work-around. Tries to to get the source file from the container first
before attempting to find it in the workspace.
DJ, if possible, please determine if this is a regression at the platform level. I don't think this is a stop-ship, but would like to check with others to determine how common development/debugging is with symbolically linked locations. Moving back to Debug to mark as RC4 candidate. Proposed fix: add a workaround in debug's source lookup to use the 3.0 based approach of source lookup when the 3.1 algorithm fails (i.e. first lookup source using the new case sensitive/relative path support algorithm, and revert to the old IContainer.getFile(...) lookup when the new algorithm finds nothing). Risk: The risk of this fix breaking anything is small to none. The only side effect is that source lookup could take a little longer (but not sure if it's measurable). It means that we will perform 2 attempts to resolve a source file in each container (directory/folder) that does not contain a source file on the source lookup path. For example, if we search in 10 folders and the file is actually in folder 8, we will do 2 resolutions in each of folders 1 thru 7 before finding it in 8 (instead of 1 resolution in each of the folders). Platform should advise if IContainer.getFile(name).exists() is expensive. Remaining issue: This will find source for the same scenarios that were supported in 3.0, but source lookup for relative path names in symbolically linked folders will still not work in 3.1, until the platform bug is addressed. If approved for RC4, we shold open a new bug against the platform for resolving IFiles for symbolically linked locations. Created bug 101036 in Core-land. Created attachment 23616 [details]
replacement patch
This patch has less whitespace manipulation than the previous patch.
Requesting Darin Swanson and DJ to vote on patch for RC4. +1. And IResource.getFile().exists() is blazingly fast. :-) +1 Applied patch to HEAD. Code reviewed by Kevin Barnes and Darin Swanson. It would be great if Venkatesh could verify this fix. The fix will be today's nightly build (available tomorrow). Should I be looking for a specific time stamped nightly build? Or just pick the latest nightly build available tomorrow morning? I believe the build will be time stamped as N20050622-0010. If it changes, I'll let you know. *** Bug 101238 has been marked as a duplicate of this bug. *** N20050622-0010 build worked for me. Thanks. verified - thanks Venkatesh *** Bug 101596 has been marked as a duplicate of this bug. *** *** Bug 101635 has been marked as a duplicate of this bug. *** |