windows - boost::recursive_mutex leaks event handles when lock contention occurs.

[al.mendall@…]

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.

[viboes]

Please, could you provide a simple example?

[viboes]

I guess that your are on windows. I have no access to windows.

Please, could you detail each one of the patches that makes your example to don't leak?

[viboes]

Please, give me more details of the point 1.

[viboes]

PING !!!

[anonymous]

Yes, the handle leak occurs in Windows. I have not experienced it in Linux. Here is a simple example class.

class UserInfo
{
    boost::recursive_mutex m_Lock;
    bool IsEntitled (const unsigned int uBit);
}

bool CUserInfo::IsEntitled (const unsigned int uBit)
{
    bool    bRet = false;
    boost::recursive_mutex::scoped_lock lock (m_Lock);
    //do something...anything that takes a few nanoseconds.
    return bRet;
}

You can see the leak by creating a simple windows app that launches multiple threads and puts them each in a loop calling IsEntitled. It will leak event handles for each (or maybe just some?) lock contention events. So the more threads you launch, the more handle leaks you will see.

[anonymous]

Yes, recursive_mutex leak handles on windows! Please help!

[viboes]

I will take a look, but I don't have a Windows platform to check it.

Niall, if you have some time, could you take a look at this issue?

[anonymous jellyfish]

I saw a rising Event handle count as described because of boost::recursive_mutex contention with many objects. But the handles aren't leaking; if I delete my array of objects, the boost::recursive_mutex destructor releases the Event handle if it created one.

So, I don't think there is a bug here. If you have an array of 100k objects each containing boost::recursive_mutex, be prepared for anywhere between 0 and 100k Event handles.

[viboes]

As we don't have an example I propose to close this issue.

[viboes]

See #13212