Community
Participate
Working Groups
The Valgrind view provides an "Export Log" feature, but it's missing a related "Import Log" button. There's 2 interesting workflows for this: I'd like to be able to import a log, such that my coworker can export his log and send to me asking for review of issues. Or, such that I can collect a log on a remote target using valgrind commandline, and then analyze it in my IDE.
The design of the Valgrind plugins has explicitly been intended for CDT users themselves _as_ they are developing/working with code. We did not want to design for post-analysis since it makes the UI hard to get right and it's difficult to ensure that the correct source code is present as projects in the IDE. If we go ahead with this, let's just make sure that we handle all the cases where we link to source code and guard them with checks that the code exists and show proper error messages or something. We'll also have to update docs to say things like "If you have the related source code in your workspace ...".
(In reply to comment #1) > The design of the Valgrind plugins has explicitly been intended for CDT users > themselves _as_ they are developing/working with code. We did not want to > design for post-analysis since it makes the UI hard to get right and it's > difficult to ensure that the correct source code is present as projects in the > IDE. > > If we go ahead with this, let's just make sure that we handle all the cases > where we link to source code and guard them with checks that the code exists > and show proper error messages or something. We'll also have to update docs to > say things like "If you have the related source code in your workspace ...". As Andrew stated, we did not design the plugins for this kind of use case. Aside from source lookup problems for importing logs on non-workspace projects, I would expect lots of parsing errors. The plugins currently make assumptions about how Valgrind was executed. For example, it sets the quiet flag and specifies an output directory. It would certainly crash if given something with verbose output, or XML output, and probably many other configurations.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I started doing implementation (hence Bug 482947) but I got a bit stuck since this Launch object is very deep everywhere I could not get rid of it from UI which would a problem for this. It is still possible to do Import by mocking it.
An import feature would be very helpful. We have some long running tests with Valgrind on our Jenkins machines and I would be happy to import the log to my workspace to analyze it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
