Daniel Stenberg wrote:
> On Sun, 18 Apr 2004, Joe Halpin wrote:
>
>
>>I found where it's happening and let the maintainer know. Valgrind plays
>> games with how memory is setup, so I'm going to let him figure it out.
>
>
>>However, he doesn't sound like he considers this a priority.
>
> Fair enough. If most options work it is still nice from most valgrind users'
> perspective.
>
>>Another possibility is to modify runtests.pl to redirect stdout to the
>>logfile, something like
>>
>>$CURL="exec 3>log/valgrind$testnum valgrind --leak-check=yes -q $CURL >&3";
>
> I fail to see how this would work similar to the current command line. I want
> valgrind's output to get stored in a separate logfile, not mixed with the
> "regular" stdout or stderr outputs.

Yes, sorry. I'm not feeling well and my head was in kind of a fog while
I was looking at this. Forgot about that part.

However, I did get a response from the maintainer, who said that
--logfile-fd expects to get an open descriptor, and was failing because
we didn't have fd 3 open when we ran it (not sure why it's different on
linux).

So the solution is to use

$CURL="valgrind --leak-check=yes --logfile-fd=3 -q $CURL
3>log/valgrind$testnum";

This will need a few changes to the script, for example $testnum isn't
visible at the point where the command is run. I've made the changes
locally and will submit a patch when I get it tested a little more.

>>I could also add some code to use watchmalloc on Solaris as well.
>
> That would be nice. If you can provide any example outputs that watchmalloc
> produces when it catches any problems it would also be cool as then we could
> start adding a function that auto-detects such failures in the output the
> tool.

Will do.

Joe
Received on 2004-04-19