Boost logo

Threads-Devel :

Subject: [Threads-devel] Leak on not joined thread / Linux / Boost 1.34.1
From: Emilio Pombo (epombo_at_[hidden])
Date: 2009-02-16 07:59:38

Hi, I'm using Boost::Threads at my work from some months ago... we are programming modules for Asterisk (the PBX Open Source), under Linux (CentOS dist and gcc 4.0).

My module was running apparently well, so test on QA department started... after some stress test under heavy load (think about all most 200000 thread launches on an hour) we found that the module was leaking, that was some kind of rare because on my devel box I had run all execution paths with Valgrind. After some accuracy tests again on my machine, also running with Valgrind, I was on the same scenario discovered on QA tests, watching top and pmap commands data, the module was leaking, but Valgrind didn't detect the leak.

After some code comments -the old style leak find method school ;)- the result was really surprising for me... the leaks were produced after each thread launch, so at this point I quickly change Boost::Thread by POSIX Thread -the default option basically on Asterisk development-, the problem was still there. After that I released that on some flows of execution the module wasn't leaking, and that flows matched with ones were I have to join the thread (on some cases my requirements force me to avoid join and terminate thread directly from launching function with no join from another thread).

Finally solved the problem with POSIX Thread, creating always detachable threads -non joinable-, and doing sync with a semaphore. I think that the problem on boost::thread was significantly the same as with POSIX, but you can't access this kind of details on boost::thread, or at least I think you must be "protected" by surround implementation from a leak if you start a thread that you never execute method ::join() from another thread -I searched on boost doc, I founded a ::detach() method, but on my version of boost at least wasn't available, may be executing this on non joinable flows could be the solution-... any comments?

Thanks in advance, regards.

Emilio Pombo
Development Team

Tel: +598 2 400-7885

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at