id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
11457	windows - boost::recursive_mutex leaks event handles when lock contention occurs.	al.mendall@…	viboes	"When 2+ threads attempt to acquire a recursive_mutex at the same time, an event handle may/will be leaked.

This is extremely reproducible in my application.  The app runs fine by the way...the leak does not interfere with the expected behavior.  It merely leaks handles at a very low rate (< 0.01% of the time the lock is acquired).  That rate increases the more threads there are trying to acquire the same locks.

1. Commenting out the call to lock the recursive_mutex eliminates the leak.
2. Replacing recursive_mutex with a non-boost lock eliminates the leak.
3. Preventing > 1 thread from trying to acquire the recursive_mutex at at time also eliminates the leak.
4. The more threads there are fighting over the lock, the more likely it is that handles will be leaked.
5. The handle leak is 100% reproducible, but the # of leaks varies with each execution.  There is an element of randomness to the quantity of handles leaked.

Those facts combine to point squarely at lock contention in recursive_mutex as the culprit.

I also used the handle.exe utility to confirm that the application was leaking event handles.


My application launches 9 threads that each traverse a vector of ~100k objects.  Each object owns a recursive_mutex.  Each threads acquires & releases each object's lock ~50 times in rapid succession.  Each time this complete cycle is run, the application will leak 250-1500 event handles."	Bugs	closed		thread	Boost 1.46.0	Problem	worksforme	handle leak recursive_mutex