Opened 4 years ago

Closed 4 years ago

#8724 closed Bugs (fixed)

bad_alloc thrown in empty list copy constructor

Reported by: gleonid@… Owned by: igaztanaga
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.

Attachments (0)

Change History (7)

comment:1 Changed 4 years ago by anonymous

  • Keywords bad_alloc interprocess container added

comment:2 Changed 4 years ago by anonymous

apologies, I have missed one include

#include <boost/container/list.hpp>

comment:3 Changed 4 years ago by igaztanaga

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

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 4 years ago by igaztanaga

  • Resolution fixed deleted
  • Status changed from closed to reopened

Sorry, I wrongly closed the issue. Reopening.

comment:5 Changed 4 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 4 years ago by igaztanaga

Yes, that patch should fix the issue.

comment:7 Changed 4 years ago by igaztanaga

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

It was fixed in Boost 1.54

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain igaztanaga.
The resolution will be deleted. Next status will be 'reopened'.

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

Note: See TracTickets for help on using tickets.