Boost C++ Libraries: Ticket #11728: interprocess::message_queue deadlocked when process exists unexpectedly on Windows

attachment set

Thu, 15 Oct 2015 07:40:41 GMT

attachment → example.zip

Code that reproduces the issue reliably

Thu, 15 Oct 2015 09:56:30 GMT

In other words, when process exits unexpectedly, it is not guaranteed that locks owned by it with kernel of file-system persistence are released, at least on Windows platforms. This could lead to very serious problems. For example, suppose multiple processes are putting log records to a viewer process using an interprocess::message_queue. When any process, be it a logger or the viewer, crashes, all processes involved may just be deadlocked.

Ion Gaztañaga — Tue, 27 Oct 2015 10:18:42 GMT

Thanks for the ticket and the test case. This is known issue since there is no guarantee for deadlock detection even in non-Windows systems, robust mutexes are not mandatory, there is no easy fix for this. In case this helps you, you can define the following before using including interprocess:

BOOST_INTERPROCESS_ENABLE_TIMEOUT_WHEN_LOCKING

and optionally define a timeout (by default 10 seconds)

BOOST_INTERPROCESS_TIMEOUT_WHEN_LOCKING_DURATION_MS

This converts any infinite mutex lock into a timed lock and throws an exception if the timeout passes. This won't if the message queue is waiting in the condition variable (one can in theory wait for a message for a long time). This could detect dead processes when trying to send a message. You can use timed receives as a workaround in reception.

It's the best we can do now. It's similar to a inter-thead communication, if a thread dies or deadlocks, then you are lost.

In any case BOOST_INTERPROCESS_ENABLE_TIMEOUT_WHEN_LOCKING, which was experimental, should be documented. Let me know if this at least alleviates the problem.

Tue, 27 Oct 2015 13:40:00 GMT

Thanks for the reply. I just thought the library is no longer maintained.

As to the issue, I think there is a not-so-difficult fix at least on Windows platforms. The keypoint is that mutex kernel object in Windows is indeed robust. Please see the description for the return value WAIT_ABANDONED on [this](https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx) MSDN page.

With a robust mutex mechanism, the fix is pretty much straightforward. First, we synthesize a name for the mutex kernel object based on the name of the message queue which is supplied by the user. Then, everytime a process tires to access the message queue, it first creates or opens the mutex with the synthesized name. Note that this does not affect the kernel or filesystem persistence nature of the message queue.

cc changed

daniel.kruegler@… — Fri, 02 Sep 2016 11:39:08 GMT

cc daniel.kruegler@… added

Arne.Brix@… — Fri, 02 Sep 2016 12:52:46 GMT

We are suffering from this problem.

On our systems (Windows 7) the mentioned Workaround helps neither using boost 1.57 nor 1.60.

Also the problem is triggered by timed_send() the same way as try_send()

This is rather critical for us, so any help would be greatly apreciated!

attachment set

Arne.Brix@… — Fri, 02 Sep 2016 12:58:02 GMT

attachment → reproducer.zip

Reproducer with workaround and using timed_send()

davids@… — Tue, 11 Jul 2017 22:34:02 GMT

Can you elaborate on this solution? How does use of the Window's named mutex prevent trying to lock an abandoned file-persistent mutex?