[Boost-bugs] [Boost C++ Libraries] #6764: rbtree_best_fit breaks if allocation alignment doesn't match the segment manager alignment

Subject: [Boost-bugs] [Boost C++ Libraries] #6764: rbtree_best_fit breaks if allocation alignment doesn't match the segment manager alignment
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-04-05 08:11:57


#6764: rbtree_best_fit breaks if allocation alignment doesn't match the segment
manager alignment
------------------------------+---------------------------------------------
 Reporter: andysem | Owner: igaztanaga
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: interprocess
  Version: Boost 1.48.0 | Severity: Regression
 Keywords: |
------------------------------+---------------------------------------------
 I have a shared memory queue. The memory segment is divided into 3 parts:
 a header, a fixed number of element descriptors and an area available for
 element bodies. The latter is managed by a segment manager with the
 rbtree_best_fit allocation strategy, which is initialized so that it
 doesn't use the area with the element descriptors.

 If the allocation strategy uses default alignment settings, everything
 works as expected. But if a stricter alignment requirement is specified
 (32 bytes in my case), the rbtree_best_fit::priv_add_segment function
 fails with assertion failure 'priv_end_block() == end_block'.

 Apparently, the root of the issue is in the fact that the segment manager
 itself in my case is not aligned to 32 bytes (but is aligned sufficiently
 to be operated on). This configuration worked fine with Boost 1.46 but
 fails with 1.48. I think, such configuration is valid and the code should
 be made to support it.

 I have attached a test case that demonstrates the issue. I'm running on
 Linux, x86-64, gcc 4.6.

 PS: I also have a side question. As you may see in the code, I try to
 estimate the shared memory segment size to allocate. I assume the segment
 manager will add an overhead per allocation for its bookkeeping but I
 failed to see how I can discover the amount of this overhead, so I
 hardcoded 64 bytes. Is there a better way to do this?

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/6764>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:09 UTC