Re: [boost] Memoryleaks in boost::pool_allocator

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-08-27 04:49:51

Hi Paul,

On Wed, Aug 27, 2008 at 2:44 AM, Paul Bormans <pbor1234_at_[hidden]> wrote:
> Some time ago i had noticed some strange behavior in the boost pool_allocator regarding its memory usage. Now that i've found these great mailinglists ;) i've reproduced the error and with some additional analysis i can post the thing here.
>

I have the same experience, although with Linux and GCC 4.1.2. More precisely:

[snip]
>
> >From these tests;
> - why does the boost::pool_allocator reserve 16312 bytes for 1000 int's while the default stl vector consumes (only) 4264 bytes?

I think it has something to do with the way the pool_allocator grows,
which is by doubling the available pool source every time it "runs out
of available free contiguous space".

> - why does a call to release_memory( ) not remove all the memory allocations done by the pool_allocator? But only the last block?

I think this is the major bug that gets exacerbated in "high data
churn applications" -- where lots of small containers acquire/release
memory often, and the pool_allocator just doesn't know about the
blocks that are supposedly "free" and "available" again.

> - why does the size of each new block gets duplicated in size (even after release_memory)?
>

This I think is the intended behavior (which I think you mean is that
the size of the whole memory block gets doubled every time).

> Does this make sense to any of you?

No, but it would be nice to know if indeed this is a bug and whether
there should be additional tests to expose the bug.

One thing I notice is that there's an interface to
pool_allocator<...>::purge_memory() -- or something similar. Is this
by any means part of the standard allocator interface and shouldn't
this be called whenever a release is called as well?

HTH

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.