You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@covalent.net on 2000/11/27 23:11:13 UTC
apr_palloc(NULL...)
One of the early hacks that was added to APR was the ability to call
apr_p(c)alloc with a NULL pool. This would make apr_p(c)alloc use malloc
internally to allocate the memory. I would like to remove this feature,
but it has some far-reaching implications if I do, so I am checking here
first.
The problem is that the support for NULL pools has always been a bit
half-assed, and it is very difficult to get it right. We really need a
more generalized set of memory routines that would allow people to
allocate from a pool, the heap, or shared memory.
I started to go through the APR code today to cleanup the NULL pool stuff,
and it is non-trivial. Think about it this way, we use pools for a lot
more than just allocating memory, we also use pools for cleaning up after
ourselves. As things stand right now, we have some serious memory leaks
in APR, because we allow people to allocate out of a NULL pool.
For example:
apr_open is called with a NULL pool, and the APR_BUFFERED flag, we will
allocate 4k on a unix machine for the buffer, that is never freed.
Even if we go through and manually free all of the allocated memory if the
pool is NULL, we still have the problem that we can't register cleanups,
so we are forcing people to manually destroy whatever variables they
create.
Can we get a quick (like within 24 hrs) decision on which direction we
want to go with this. I plan to make the change quickly, either cleaning
up the memory leaks by manually freeing them, or removing the NULL pool
hack.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: apr_palloc(NULL...)
Posted by Greg Stein <gs...@lyra.org>.
Hrm. We can't create a subpool for each and every file. Each subpool costs a
minimum of 8k of memory. Using a subpool for just the NULL-pool files will
add complexity and only solve NULL-pools for the file case; I'd hate to see
that complexity ripple through all of the types to deal with a feature that
we aren't sure about anyways.
I'd say that we toss the NULL pool feature.
Your fix for the permanent_pool is dead-on, however. I didn't realize that
problem had existed(!).
Regarding the multiple types of allocs... weren't we going to do that by
configuring a pool a bit differently? (e.g. have an explicit "malloc-style
pool" rather than using p==NULL to signify that)
Cheers,
-g
On Mon, Nov 27, 2000 at 06:52:30PM -0800, rbb@covalent.net wrote:
>
> Just spoke to Will Rowe, and we have a potentially cleaner
> solution. Basically, we fix the make_sub_pool function so that if we call
> it twice with a NULL pool, we just assign the second root pool to be a
> child of the permanent_pool. This keeps us from blowing away the
> permanent pool, which is goodness.
>
> This also allows us to create a new root pool whenever we call
> apr_p(c)alloc with a NULL pool. So, basically, we would do this if we
> called apr_open with a NULL pool:
>
> apr_open(&fd,..... NULL);
> fd->cntxt = apr_make_pool(NULL, ...);
> ....
>
> apr_close(fd)
> ap_destroy_pool(fd..)
>
> This will require a flag to determine if we created the pool or not, but
> that is a minimal addition.
>
> Ryan
>
>
> On Mon, 27 Nov 2000 rbb@covalent.net wrote:
>
> >
> > One of the early hacks that was added to APR was the ability to call
> > apr_p(c)alloc with a NULL pool. This would make apr_p(c)alloc use malloc
> > internally to allocate the memory. I would like to remove this feature,
> > but it has some far-reaching implications if I do, so I am checking here
> > first.
> >
> > The problem is that the support for NULL pools has always been a bit
> > half-assed, and it is very difficult to get it right. We really need a
> > more generalized set of memory routines that would allow people to
> > allocate from a pool, the heap, or shared memory.
> >
> > I started to go through the APR code today to cleanup the NULL pool stuff,
> > and it is non-trivial. Think about it this way, we use pools for a lot
> > more than just allocating memory, we also use pools for cleaning up after
> > ourselves. As things stand right now, we have some serious memory leaks
> > in APR, because we allow people to allocate out of a NULL pool.
> >
> > For example:
> >
> > apr_open is called with a NULL pool, and the APR_BUFFERED flag, we will
> > allocate 4k on a unix machine for the buffer, that is never freed.
> >
> > Even if we go through and manually free all of the allocated memory if the
> > pool is NULL, we still have the problem that we can't register cleanups,
> > so we are forcing people to manually destroy whatever variables they
> > create.
> >
> > Can we get a quick (like within 24 hrs) decision on which direction we
> > want to go with this. I plan to make the change quickly, either cleaning
> > up the memory leaks by manually freeing them, or removing the NULL pool
> > hack.
> >
> > Ryan
> >
> >
> > _______________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
> >
> >
> >
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
--
Greg Stein, http://www.lyra.org/
Re: apr_palloc(NULL...)
Posted by rb...@covalent.net.
Just spoke to Will Rowe, and we have a potentially cleaner
solution. Basically, we fix the make_sub_pool function so that if we call
it twice with a NULL pool, we just assign the second root pool to be a
child of the permanent_pool. This keeps us from blowing away the
permanent pool, which is goodness.
This also allows us to create a new root pool whenever we call
apr_p(c)alloc with a NULL pool. So, basically, we would do this if we
called apr_open with a NULL pool:
apr_open(&fd,..... NULL);
fd->cntxt = apr_make_pool(NULL, ...);
....
apr_close(fd)
ap_destroy_pool(fd..)
This will require a flag to determine if we created the pool or not, but
that is a minimal addition.
Ryan
On Mon, 27 Nov 2000 rbb@covalent.net wrote:
>
> One of the early hacks that was added to APR was the ability to call
> apr_p(c)alloc with a NULL pool. This would make apr_p(c)alloc use malloc
> internally to allocate the memory. I would like to remove this feature,
> but it has some far-reaching implications if I do, so I am checking here
> first.
>
> The problem is that the support for NULL pools has always been a bit
> half-assed, and it is very difficult to get it right. We really need a
> more generalized set of memory routines that would allow people to
> allocate from a pool, the heap, or shared memory.
>
> I started to go through the APR code today to cleanup the NULL pool stuff,
> and it is non-trivial. Think about it this way, we use pools for a lot
> more than just allocating memory, we also use pools for cleaning up after
> ourselves. As things stand right now, we have some serious memory leaks
> in APR, because we allow people to allocate out of a NULL pool.
>
> For example:
>
> apr_open is called with a NULL pool, and the APR_BUFFERED flag, we will
> allocate 4k on a unix machine for the buffer, that is never freed.
>
> Even if we go through and manually free all of the allocated memory if the
> pool is NULL, we still have the problem that we can't register cleanups,
> so we are forcing people to manually destroy whatever variables they
> create.
>
> Can we get a quick (like within 24 hrs) decision on which direction we
> want to go with this. I plan to make the change quickly, either cleaning
> up the memory leaks by manually freeing them, or removing the NULL pool
> hack.
>
> Ryan
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
>
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------