Community
Participate
Working Groups
I'm trying a simple C autotools project with the latest test Helios RC2 EPP build [1] on x86 and x86_64 Fedora 12 and I don't see error markers in my source file. When I double click on the memcheck error with the source file and line number, it opens up a copy of the file but not the one in the project (it doesn't have the .c file icon, the existing file from the workspace remains open in an editor, etc.). File -> New -> C Project GNU Autotools -> Hello World ANSI C Autotools Project -> (name, etc.) ... Finish in src/<your source file>.c, add a line in main(void): void *a = malloc(8); Project -> Clean Right-click -> Profile As -> Profile with Valgrind Valgrind view comes up, expand "8 bytes in 1 block are definitely lost ...", double-click on the entry with the line number The odd thing is that it works fine with a managed make project. This should really be fixed for 0.6 (Helios).
Oops, I forgot to include the download link for the EPP packages (look for "LinuxDev"): http://www.eclipse.org/epp/download.php
This bug occurs because ValgrindLaunchConfigurationDelegate has the following: if (frame.getLine() > 0) { ISourceLocator locator = frame.getLaunch().getSourceLocator(); ISourceLookupResult result = DebugUITools.lookupSource(frame.getFile(), locator); Object sourceElement = result.getSourceElement(); if (sourceElement != null && sourceElement instanceof IResource) { IResource resource = (IResource) sourceElement; marker = resource.createMarker(ValgrindLaunchPlugin.MARKER_TYPE); What is happening is the locator ends up being CSourceLookupDirector. This ends up invoking the CSourceLookupParticipant which goes through the containers one by one looking for the first match to find the source. The first container: AbsolutePath fails on "hello.c". The 2nd container: RelativePath succeeds because the executable and the source file end up being in the same directory by default in an Autotools hello world project. So, it returns a LocalFileStorage which encapsulates the java.io.File for ${your_path}/hello.c. The code above is not ready for this and fails the IResource test so no markers are recorded. In the case of a ManagedMake project, the build directory is never the top-level directory so the executable and the source are always in different directories and so the RelativePath container check above fails. It then tries the 3rd and last container check which is the ProjectContainer. This finds an IFile for hello.c under the Project. An IFile is an IResource so the code above will create the marker. The code needs to be adjusted to either record annotations directly using the annotation model or else find another way to get the source IFile in the Workspace.
Thanks for investigating Jeff. It now checks for a LocalFileStorage being returned from source lookup, and then finds the corresponding IResource. This fixes both the marker issue and the duplicate editor issue.
I can verify that with this change (in the latest nightly build) double-clicking on the element in the Valgrind view brings me to the correct editor and doesn't double-open it. Thanks for the quick resolution.
