Modify

Ticket #3951 (closed Bugs: fixed)

Opened 4 years ago

Last modified 4 years ago

assertion failed calling find<> in managed_shared_memory (might be a bug in g++)

Reported by: Xavi Gratal <gratal@…> Owned by: igaztanaga
Milestone: Boost 1.45.0 Component: interprocess
Version: Boost 1.42.0 Severity: Problem
Keywords: Cc:

Description

I am getting the following assertion failed

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

when compiling the extremely simple attached program in GCC 4.4.3 with optimization on (-O2 or -O3)

it doesn't happen with -O0 or -O1, or if I use -fno-strict-aliasing on top of -O2.

I have also got this assertion failed error with GCC 4.4.1, but I wasn't able to isolate it into a simple program.

The bug depends a lot on the GCC version and the optimization options, so I guess it is a bug in the compiler, but it affects the usability of boost, so I think it is worth reporting it here

Attachments

ipc.cc Download (268 bytes) - added by Xavi Gratal <gratal@…> 4 years ago.
source code that triggers the error

Change History

Changed 4 years ago by Xavi Gratal <gratal@…>

source code that triggers the error

comment:1 Changed 4 years ago by Xavi Gratal <gratal@…>

I forgot to say that I am using linux, and I tried this in both the Ubuntu Lucid Lynx alpha, which comes with gcc 4.4.3, and compiling gcc 4.4.3 myself in Ubuntu Karmic Koala.

As I said, the bug is triggered for the attaches source code only in gcc 4.4.3, but the same problem appears in more complex programs also in the gcc 4.4.1 which ships with Karmic Koala.

It happens both in boost 1.42.0 and 1.41.0. Actually I think the interprocess library didn't change between them.

Looking at the code of interprocess, it doesn't seem a strict aliasing problem, and the code compiles without warning with -Wstrict-aliasing=2 enabled.

comment:2 Changed 4 years ago by Lénaïc Huard <lhuard@…>

Hello,

This issue and #3950 look like dupes. It seems that some gcc optimizations are breaking the boost code attempting to emulate Rvalue references. When your piece of code is compiled with -std=c++x0 or -std=gnu++0x, gcc handles Rvalue references, boost tricks become useless and the piece of code works.

comment:3 Changed 4 years ago by Lénaïc Huard <lhuard@…>

Hello Xavi,

Could you please try the  boost_interprocess.patch attached in #3950 and validate that it fixes all your issues?

Thanks Lénaïc.

comment:4 Changed 4 years ago by gratal@…

Hi,

I tried it with some examples and everything worked fine.

Do you know when this will make it into the svn trunk?

Thanks!

comment:5 Changed 4 years ago by igaztanaga

  • Status changed from new to closed
  • Resolution set to fixed
  • Milestone changed from Boost 1.43.0 to Boost-1.45.0

Fixed for Boost 1.45 in release branch

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.