Opened 5 years ago

Closed 5 years ago

#8724 closed Bugs (fixed)

bad_alloc thrown in empty list copy constructor

Reported by: gleonid@… Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.53.0 Severity: Problem
Keywords: bad_alloc interprocess container Cc:


I am running RHEL 5.

Compiler - gcc 4.1.2

following code fragment compiled against boost 1.53.0 throws bad_alloc exception at run time.

Essentially I have an empty ::boost::container::list object allocated in shared memory (segment_manager from boost interprocess). attempt to copy such empty list causes bad_alloc exception

#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/interprocess/managed_external_buffer.hpp>


typedef ::boost::interprocess::allocator<int, ::boost::interprocess::managed_external_buffer::segment_manager> int_allocator;
typedef ::boost::container::list<int, int_allocator> int_list;
char g_memory_buf[1024];


int main()
    ::boost::interprocess::managed_external_buffer segment(::boost::interprocess::create_only, g_memory_buf, sizeof(g_memory_buf));

    // 1. construct empty list
    int_list *l1 = segment.construct<int_list>("1")(int_allocator(segment.get_segment_manager()));

    // 2. use copy constructor

    return 0;

when same code is compiled against boost 1.51.0 - no exceptions. I wonder if this behavioral change was intentional.

Change History (7)

comment:1 Changed 5 years ago by anonymous

Keywords: bad_alloc interprocess container added

comment:2 Changed 5 years ago by anonymous

apologies, I have missed one include

#include <boost/container/list.hpp>

comment:3 Changed 5 years ago by Ion Gaztañaga

Resolution: fixed
Status: newclosed

Thanks for the report. It's a bug.

To get a workaround, modify allocate_many_and_construct() function of boost/container/detail/node_alloc_holder.hpp file so that if "n" is zero, no code is executed. This function should do nothing if "difference_type n" argument is zero (as it's your case, since the source container is empty.

comment:4 Changed 5 years ago by Ion Gaztañaga

Resolution: fixed
Status: closedreopened

Sorry, I wrongly closed the issue. Reopening.

comment:5 Changed 5 years ago by gleonid@…

please confirm that following is a correct patch

--- boost-1.53.0/boost/container/detail/node_alloc_holder.hpp.orig     2013-06-25 17:14:06.000000000 -0400
+++ boost-1.53.0/boost/container/detail/node_alloc_holder.hpp  2013-06-25 17:14:37.000000000 -0400
@@ -239,6 +239,8 @@
       ::new(static_cast<hook_type*>(container_detail::to_raw_pointer(p))) hook_type;
       return (p);
+      if (!n)
+         return;
       typedef typename NodeAlloc::multiallocation_chain multiallocation_chain;

       //Try to allocate memory in a single block

comment:6 Changed 5 years ago by Ion Gaztañaga

Yes, that patch should fix the issue.

comment:7 Changed 5 years ago by Ion Gaztañaga

Resolution: fixed
Status: reopenedclosed

It was fixed in Boost 1.54

Note: See TracTickets for help on using tickets.