Re: [Boost-users] [interprocess] managed_shm->find call causes assertion

Subject: Re: [Boost-users] [interprocess] managed_shm->find call causes assertion
From: Moritz (mokoman_at_[hidden])
Date: 2010-04-09 12:19:59

It returns [EPERM]. I now also observed that the code works with 
templates if I compile it with -O1. If -O2 or -O3 is used, the assertion 
  occurs.
It also does not occur if I shorten the destructor of the class. That 
means I simply remove some "delete some_named_mutex;" statements and 
then no assertion hits! This code is not related to problematic code and 
is even not executed at the time I try to retrieve an object from shared 
memory.
Because of this I now think that gcc messes up the optimized code or I 
made a major programming mistake.

System:
Ubuntu 9.10
Boost: 1.40
gcc version 4.4.1

Ion Gaztañaga wrote:
>> If I remove the template and add a type the assert will not appear.
>>
>> I am confused ...
> 
> So am I. What does pthread_mutex_unlock return when failing? According 
> to POSIX it should be one of these:
> 
> The pthread_mutex_lock(), pthread_mutex_trylock(), and 
> pthread_mutex_unlock() functions may fail if:
> 
> [EINVAL]
>     The value specified by mutex does not refer to an initialized mutex 
> object.
> 
> [EAGAIN]
>     [XSI] [Option Start] The mutex could not be acquired because the 
> maximum number of recursive locks for mutex has been exceeded. [Option End]
> 
> The pthread_mutex_unlock() function may fail if:
> 
> [EPERM]
>     The current thread does not own the mutex.
> 
> These functions shall not return an error code of [EINTR]
> 
> Best,
> 
> Ion