Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2 Memory leak on Windows

open
nobody
None
5
2009-04-06
2009-04-06
Anonymous
No

Using Visual Studio 9, we have detected memory leaks when using the threadpool library. Unfortunately, we do not have the time right now to debug it for you, so I am posting this in the hopes that you can take a look and maybe it is a quick fix for you. Basically, this method:

static void create_and_attach(shared_ptr<pool_type> const & pool)
{
shared_ptr<worker_thread> worker(new worker_thread(pool));
if(worker)
{
worker->m_thread.reset(new boost::thread(bind(&worker_thread::run, worker)));
}
}

creates new worker threads. As best I can tell, this is where the memory is being leaked. It looks like the worker and/or the pool are not getting released properly. I looked through and see that you are using shared pointers, so maybe the reference count is not getting decremented properly. Again, I haven't had the time to look more closely at it. To reproduce, basically just use this code (run it from Visual Studio):

#include <boost/threadpool.hpp>

#ifdef WIN32
#include <crtdbg.h>
#endif

int main()
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

boost::threadpool::pool pool( 1 );

return 0;
}

Please let me know if you need any clarification or additional information. Thanks!

Discussion

  • Benoit Hamet
    Benoit Hamet
    2009-04-08

    Hi all,

    Got the same problem under valgrind and AMD64 machines.

    Take me the day to found why, should have been reading here before :(.

    The problem is the "fix" for ~pool hanging (previous bug report). using m_active_worker_count in the line 304 at pool_core.cpp implies that in reality that no threads are able to quit due to lock being owner at the same time ... so the call to self->m_task_or_terminate_workers_event.notify_all(); never increment the m_active_worker_count in execute_task and is never executed ...

    putting m_worker_count there solve the problem.

    but that will not solve the previous bug. Pitty that he doesn't provide a test case ...
    Anyway it works perfectly here, as far as I see (ie : less work than threads, or more work than threads)

    Regards,

    Benoît.

     
  • I have met the same problem these day... : (

     
  • Michael Moritz
    Michael Moritz
    2009-09-22

    I can confirm this on x386 and amd64. Leakage here is huge actually. Can someone confirm this? I'll send a valgrind memcheck report soon.
    Maybe needs starting a new thread as it's not windows specific