Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 314680

Summary:	No memcheck error markers shown with autotools project
Product:	[Tools] Linux Tools	Reporter:	Andrew Overholt <overholt>
Component:	Valgrind	Assignee:	Elliott Baron <ebaron>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jjohnstn
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Andrew Overholt

2010-05-27 10:32:12 EDT

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).

Comment 1 Andrew Overholt

2010-05-27 10:34:02 EDT

Oops, I forgot to include the download link for the EPP packages (look for "LinuxDev"):

http://www.eclipse.org/epp/download.php

Comment 2 Jeff Johnston

2010-05-27 20:56:08 EDT

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.

Comment 3 Elliott Baron

2010-05-28 19:53:51 EDT

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.

Comment 4 Andrew Overholt

2010-05-31 09:31:52 EDT

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.