Subject: Re: memory (leak) debugging

Re: memory (leak) debugging

From: Daniel Johnson <>
Date: Tue, 31 Mar 2009 10:16:44 -0400

On Mar 30, 2009, at 4:39 AM, Daniel Stenberg wrote:

> On Mon, 30 Mar 2009, Simon Josefsson wrote:
>> I gave up on dmalloc a long time ago, in my experience valgrind
>> leads to
>> better results and doesn't require changes to the build.
>> In most of my other projects, I always set up so that the self-
>> tests are run
>> under valgrind automatically (if valgrind is installed). Maybe
>> that would
>> help libssh2? We need more self-tests, though...
> Yes, we need more self-tests and running them with valgrind is a
> good way to
> catch most of the problems. But there are two buts here that our
> current leak
> (Daniel Johnson's report) shows us where just relying on valgrind
> isn't good
> enough:
> A) valgrind slows down the execution a lot. I can get the leak to
> occur in my
> tests but it seems virtually impossible to make happen when
> valgrind
> monitors/slows down the code. A plain memory-leak detection
> would be
> almost no extra overhead.
> B) when people detect leaks on non-valgrind platforms

There is now a Darwin branch in the valgrind repo! I've checked it
out, build it and run a curl test build with it successfully. It's
incomplete and buggy, but it works well enough for the curl test
suite. I just thought I'd share that with you. I'm going to be using
it from now on.

I did notice that the libssh2-related tests explicitly disable
valgrind use, so it wouldn't have helped in this case.



libssh2-devel mailing list

Received on 2009-03-31