Re: [boost] [EXTERNAL] [interprocess] leaked named mutexes

Subject: Re: [boost] [EXTERNAL] [interprocess] leaked named mutexes
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2013-03-06 18:02:22

On Mar 6, 2013, at 3:51 PM, Eric Niebler wrote:

> I recently discovered that a process can very easily leave a named mutex
> dangling. Consider the following:
> 
> #include <cstdlib>
> #include <iostream>
> #include <boost/interprocess/sync/named_mutex.hpp>
> #include <boost/interprocess/sync/scoped_lock.hpp>
> namespace ip = boost::interprocess;
> 
> char const *name = "mynamedmutex";
> 
> int main(int argc, char*argv[])
> {
>  ip::named_mutex mtx(ip::open_or_create, name);
>  std::cout << "acquiring named mutex" << std::endl;
>  ip::scoped_lock<ip::named_mutex> lock(mtx);
>  std::cout << "acquired" << std::endl;
>  exit(EXIT_FAILURE); // whoops
> }
> 
> On my Linux box, this runs fine the first time, but the second time it
> hangs waiting to acquire the mutex. I have to manually delete the
> semaphore in /dev/shm/.
> 
> This will happen whenever the process exits without calling destructors
> of locals; for instance:
> 
> - std::exit
> - std::quick_exit
> - std::abort
> - std::terminate
> - a crash
> - assert failure
> - an unhandled exception
> - etc..
> 
> I find I can handle *some* of this by registering a terminate handler,
> an exit handler (and on C++11, a quick_exit handler) that calls
> boost::interprocess::named_mutex::remove. This raises a few questions,
> though...
> 
> - Is there a better way?
> - Is it safe to `remove` the same named mutex multiple times?
> - Does this clean up only this process's use of the named_mutex, or does
> it nuke it from the system, even if another process is using it? (The
> docs suggest the latter, which is not what I want, is it?)

Hi Eric,

If ipcs lists your named entity, ipcrm should remove it.  I'm not sure how boost::ip objects are created so these commands may not help you.

-- Noel