Modify

Ticket #4452 (closed Bugs: fixed)

Opened 4 years ago

Last modified 2 years ago

NDEBUG causes segv in interprocess::managed_mapped_file

Reported by: Richard Murphy <richard.murphy@…> Owned by: igaztanaga
Milestone: Boost 1.48.0 Component: interprocess
Version: Boost 1.46.1 Severity: Problem
Keywords: NDEBUG interprocess segv Cc:

Description

I have a small test program that uses interprocess::managed_mapped_file almost identically to one of the interprocess library examples - instead of using managed_shared_memory it uses the managed_mapped_file.

The program works fine unless -DNDEBUG is set. If -DNDEBUG is set then the program segvs whilst contructing the managed_mapped_file.

Attachments

boost-interprocess-bug-report.cpp Download (2.2 KB) - added by Richard Murphy <richard.murphy@…> 4 years ago.

Change History

Changed 4 years ago by Richard Murphy <richard.murphy@…>

comment:1 Changed 3 years ago by igaztanaga

  • Status changed from new to closed
  • Resolution set to invalid

I could not reproduce the bug, I close this as wontfix and reopen it if the bug is reported by another user.

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

  • Status changed from closed to reopened
  • Version changed from Boost 1.43.0 to Boost 1.46.1
  • Resolution invalid deleted
  • Milestone changed from Boost 1.44.0 to Boost 1.48.0

I have exactly the same problem with Boost 1.46.1 and even managed to reproduce it with a smaller program.

Here is the code that reproduces the issue:

#include <cstdlib>
#include <boost/interprocess/managed_shared_memory.hpp>

int main()
{
        boost::interprocess::managed_shared_memory aShm( boost::interprocess::create_only, "/toto", 4096 );
        return EXIT_SUCCESS;
}

In my case, this piece of code works when compiled with g++ 4.4. But this program segvs when compiled:

  • with g++ 4.5 or g++ 4.6;
  • with -DNDEBUG (this is really what triggers the bug);
  • with optimizations enabled. -O1 is enough.

I had a look at that and managed to have the above program work with g++-4.6 -O1 -DNDEBUG by one patch on intrusive/detail/tree_algorithms.hpp:

--- /usr/include/boost/intrusive/detail/tree_algorithms.hpp     2011-06-12 08:15:00.000000000 +0200
+++ boost_patch/include/boost/intrusive/detail/tree_algorithms.hpp      2011-07-02 18:09:02.504756424 +0200
@@ -902,6 +902,7 @@
    {
       //Check if commit_data has not been initialized by a insert_unique_check call.
       BOOST_INTRUSIVE_INVARIANT_ASSERT(commit_data.node != 0);
+      ((commit_data.node != 0) ? static_cast<void> (0) : abort());
       node_ptr parent_node(commit_data.node);
       if(parent_node == header){
          NodeTraits::set_parent(header, new_node);

This patch makes the above program works when compiled with -O1 but is not enough for higher level of optimizations. With -O2 and above and the above patch, the program keeps on segfaulting.

This is obviously not an acceptable patch and I need to better understand the issue, but I hope this gives a clue.

comment:3 follow-up: ↓ 4 Changed 2 years ago by clint@…

I've noticed in gcc 4.5.0 that passing the -fno-tree-pta seems to clear up the issue on all optimization levels.

There is a known issue with pointer analysis in 4.5.0 that this specific fix may be related to.

comment:4 in reply to: ↑ 3 Changed 2 years ago by anonymous

Replying to clint@…:

I've noticed in gcc 4.5.0 that passing the -fno-tree-pta seems to clear up the issue on all optimization levels.

There is a known issue with pointer analysis in 4.5.0 that this specific fix may be related to.

Upon further investigation, this work around doesn't actually solve the problem. Instead, it merely delayed the segmentation fault for my use case.

comment:5 Changed 2 years ago by igaztanaga

  • Status changed from reopened to closed
  • Resolution set to fixed

This was fixed in Boost 1.48 marking offset_ptr operations as non-inlineable.

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.