Platform: Win32, VC 7 & VC 8.1.
I have run into a problem using fast_pool_allocator across DLLs: it
'leaks' memory.
In this example, DLL A:
1. declares a container type that uses fast_pool_allocator
2. provides a function to populate the container type
DLL B creates instance(s) of the container type & calls DLL A to
populate those instances.
DLL A
-----
struct S
{
/* A bunch of data */
};
typedef std::list container_of_s;
/* Fills s with a number of S instances */
void dll_populate_container_of_s(container_of_s &s);
DLL B
-----
void fun_a()
{
for (int nLoop=0; nLoop<100; ++nLoop)
{
container_of_s sc;
dll_populate_container_of_s(sc);
/* manipulate sc in some way */
/* sc is destroyed, but memory is not returned to the
pool it was allocated from */
}
}
The problem is that the memory allocated by fast_pool_allocator inside
DLL A (by dll_populate_container_of_s) is not returned to the same pool
it was allocated from. I've tracked this down to fast_pool_allocator
being backed by a singleton. It turns out that each DLL get's it's own
copy of that singleton. So the memory allocated by
fast_pool_allocator<S> inside DLL A is returned to a different
fast_pool_allocator<S> inside DLL B.
Technically not a leak, but the end result is that repeated calls to
dll_populate_container_of_s cause more & more memory to be consumed.
Does anyone have a solution or workaround for this? Or an alternate pool
allocator?
Thanks
Andrew
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
