Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Sep 2002 12:01:47 +1000
From:      Tim Robbins <tjr@FreeBSD.org>
To:        Barney Wolff <barney@tp.databus.com>
Cc:        David Schultz <dschultz@uclink.Berkeley.EDU>, Peter Jeremy <peter.jeremy@alcatel.com.au>, stable@FreeBSD.org
Subject:   Re: [v]asprintf leaks memory
Message-ID:  <20020926120147.A84266@dilbert.robbins.dropbear.id.au>
In-Reply-To: <20020925231441.GA8968@tp.databus.com>; from barney@tp.databus.com on Wed, Sep 25, 2002 at 07:14:41PM -0400
References:  <20020925133219.GA59210@HAL9000.homeunix.com> <20020925214322.GL495@gsmx07.alcatel.com.au> <20020925230236.GA60375@HAL9000.homeunix.com> <20020925231441.GA8968@tp.databus.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 25, 2002 at 07:14:41PM -0400, Barney Wolff wrote:

> On Wed, Sep 25, 2002 at 04:02:37PM -0700, David Schultz wrote:
> > 
> > I don't really care one way or the other, but regardless of what
> > the manpage says, reallocf()'s semantics should probably match the
> > way it's already used.  Maybe what I found was an isolated bug and
> > reallocf() DTRT already.  In that case, the patch I posted should
> > probably be applied.
> 
> Could you please explain exactly how the original code leaks memory?
> Maybe I'm being dense today but I just don't see it.  If reallocf
> returns NULL the original buffer has been freed.

The asprintf() function works by allocating a relatively small (128 byte)
buffer for the data, then it calls __svfprintf() which calls __sfvwrite()
to write the data to the "file" (which is really a string). If __sfvwrite()
can't get enough memory for a bigger buffer, it sets fp->_bf._base to NULL
but does not change fp->_bf._size. When control returns to asprintf(),
it realloc()'s _bf._base to be _bf._size + 1 byte long. Because _bf._base
is already NULL, the call which was designed to shrink the buffer actually
allocates a new one (!) and returns the freshly allocated storage back
to the caller (!).

I'll apply David's patch...


Tim

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020926120147.A84266>