Hi again, the problem seems to be that I work with templates. I wrote a method that looks like this: template <typename ObjectType> ObjectType * get_object_pointer() const { std::pair p = _managed_shm->find<ObjectType>( ipc::unique_instance ); return p.first; } If I remove the template and add a type the assert will not appear. I am confused ... Moritz wrote:

Hi,

posted the wrong line number. Should be 107:

inline void interprocess_recursive_mutex::unlock() { int res = 0; res = pthread_mutex_unlock(&m_mut); assert(res == 0); // <- HERE! }

Moritz wrote:

...

Hi,

I have a managed_shared_memory segment which contains a unique_instance of an object. When I try to call managed_shm->find<ObjectType>( ipc::unique_instance );

I get the following assertion:

/usr/include/boost/interprocess/sync/posix/interprocess_recursive_mutex.hpp:110: void boost::interprocess::interprocess_recursive_mutex::unlock(): Assertion `res == 0' failed. Aborted

This only happens in Release-Mode (with gcc -s -O2). I am not able to build a minimum example but I also can not track the problem. Any suggests?

Kind regards

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

The assertion only occurs in Boost 1.40 not in 1.36. Is this known behavior? Kind regards, Moritz Ion Gaztañaga wrote:

On 09/04/2010 18:19, Moritz wrote:

...

Because of this I now think that gcc messes up the optimized code or I made a major programming mistake.

A similar bug has been reported to Boost.Trac and I think it's related to a gcc optimization bug.

Best,

Ion