Modify

Ticket #8724 (closed Bugs: fixed)

Opened 10 months ago

Last modified 9 months ago

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:

Description

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>

namespace
{

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
    segment.construct<int_list>("2")(*l1);

    return 0;
}

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

Attachments

Change History

comment:1 Changed 10 months ago by anonymous

  • Keywords bad_alloc interprocess container added

comment:2 Changed 10 months ago by anonymous

apologies, I have missed one include

#include <boost/container/list.hpp>

comment:3 Changed 10 months ago by igaztanaga

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

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 10 months ago by igaztanaga

  • Status changed from closed to reopened
  • Resolution fixed deleted

Sorry, I wrongly closed the issue. Reopening.

comment:5 Changed 10 months 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 10 months ago by igaztanaga

Yes, that patch should fix the issue.

comment:7 Changed 9 months ago by igaztanaga

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

It was fixed in Boost 1.54

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.