Community
Participate
Working Groups
A new issue appears to have surfaced with Indigo RC2. When I profile my app using valgrind, and it finds an error those issues are decorated, and problem entries generated. But even after I fix the code and recompile the problem entries remain. And with this latest release those problems are treatedd as errors capable of preventing a relaunch.
Created attachment 196831 [details] Screencap of error
After restarting Eclipse the error went away... until I realized what the trigger was. I believe its when I activate the Problems view that it picks up the Valgrind error. If I don't activate that view, I can rebuild and relaunch without issue.
I'm pretty sure the problem markers don't go away until re-launch under Valgrind. Elliott?
I seem to recall error markers going away after a rebuild. The functionality should be the same as the CDT does. The Valgrind marker simply extends the CDT's problem marker. I'll have to look into if the CDT does anything special to clear them on rebuild.
I'm not seeing this issue with Indigo RC2 and CDT 8.0. I have a test project, which mallocs some memory, without freeing it. I profile it with Valgrind, the error is reported and marked in the editor. If I clean or rebuild, the marker disappears. I am able to run the program without being prompted that there are errors.
Ladar, can you explain what you installed and steps we can use to reproduce the bug? Thanks!
Created attachment 197244 [details] versions...
When I tried making a home movie of the bug it got spooked and went into hiding. Like I mentioned above, it only seems to happen intermittently. Using Indigo RC2. Will try to capture a movie the next time I see it...
Thanks, Ladar. Sorry to hear it's intermittent. Hopefully we can sort it out.
I just tested our latest build from here: http://download.eclipse.org/technology/linuxtools/updates-nightly/ and cannot reproduce this problem. If I rebuild my project, the Valgrind errors are all cleared from the problems view and the Valgrind view and the markers in affected editors are removed.
You might want to test what happens if the valgrind marker appears in a referenced C project. In my case the reference was NOT pointing at the active build configuration for the project. I've noticed problems with how CDT is tracking changes in referenced projects and I suspect that issue may have played a role. I updated to RC3 this morning. If the issue resurfaces I'll let you know.
The referenced projects and active build configuration are not things I was aware was at play here. I've updated the summary to reflect this. Feel free to correct it if I'm wrong.
Unsetting target milestone for old bugs.
I managed to capture a video showing the bug. The error dialog shows up towards the end. I remove the comments from the project being profiled and attempt a relaunch. The projects compile sucessfully but I since the valgrind markers don't clear out I get an error dialog. Manually cleaning the project clears the markers so that a subsequent launch attempt succeeds. I didn't realize the importance of my project relationships when I initially posted the bug. But in case your curious, magma.check references magma, and magma references magma.so. The markers are showing up in magma.so. I can provide more details offline if necessary.
Created attachment 197568 [details] Managed to capture a video with the bug. Managed to capture a video with the bug.
Reassigning so I know the proper people see the updated info. Also confirming the bug is still present in Indigo RC3.
Just to be clear: it's too late for Indigo but we can investigate for Indigo Service Release 1 in September.
> Just to be clear: it's too late for Indigo but we can investigate for Indigo > Service Release 1 in September. That's your call. I just figured it would be one of those silly but impactful bugs. My guess is that when the CDT builder runs against my check project it is smart enough to clear the Valgrind problem markers on that project, but not smart enough to see and remove the Valgrind markers on the referenced project; that is until it comes time to run the Valgrind launcher. The reason I think its silly is that it _should_ be easy to fix. It would be reasonable to simplify the logic into clearing any (and all) workspace Valgrind markers before a new launcher executes (Valgrind or otherwise). But until the fix is ready the easiest way to workaround the issue seems is 'cleaning' the project. Interestingly enough a clean operation will remove the Valgrind markers on the referenced project even though the referenced project isn't being modified...
The error markers are particulary annoying in following workflow: 1. Memcheck my app --> errors found 2. Massif my app --> Dialog: "Errors exist in a required project. Continue Launch?" This dialog is confusing, since the memcheck errors are different in kind than real build errors. It took me a while to figure out that I can safely continue my Launch. I think that memcheck issues should generally be reported as warnings, not errors. Navigating the issues is nicely possible from the Valgrind View - so there's IMO no reason marking them up as errors.
I have analyzed the situation and found 3 distinct scenarios / workflows in which valgrind plugins don't clear their error markers. See bug 360085, I also added a sample project and steps to reproduce. I would suggest closing this bug as a duplicate of bug 360085, unless you'd like to treat the 3 distinct scenarios in separate bugs (then this can remain as a "dependency of bug 360085).
Thanks for the thorough analysis and patch, Martin! Closing as a dupe as you suggest. *** This bug has been marked as a duplicate of bug 360085 ***
