I have encountered a minor bug with boost::interprocess::vector<> which involves a situation where std::uninitialized_copy() is invoked with a NULL pointer value, and length of 0. I’m not sure if that is truly an error, but unfortunately the MWVC (9.0) debug library has an assertion which gets tripped by the null pointer value, so I've had little choice but to patch my copy of the code to prevent that call from happening. Let me know if you want me to create a trac item for this problem. The problem occurs when an empty vector (created by the single allocator argument constructor) is swapped with a vector that has an established capacity. Specifically, I see this with the following code: boost::interprocess::vector<char,char_alloc_type> *buffer = somewhere_in_shared_memory; // can’t construct ovectorstream to use buffer directly, but can swap it into place: boost::interprocess::basic_ovectorstream< buffer_t<void_alloc_t> > vstream(buffer->get_allocator()); vstream.swap_vector(*buffer); On msvc (9.0), somewhere below priv_range_insert(), a call gets issued to std::uninitialized_copy with a null pointer and length of 0. My solution to this was to modify vector::swap as follows: diff -r ./containers/container/vector.hpp ../../../../boost_1_39_0/boost/interprocess/containers/container/vector.hpp 1206,1208c1206,1210 < this->reserve(new_size); < containers_detail::default_construct_aux_proxy<T, T*, size_type> proxy(n); < priv_range_insert(this->cend().get_ptr(), n, proxy); ---

if (n>0) { this->reserve(new_size); containers_detail::default_construct_aux_proxy<T, T*, size_type> proxy(n); priv_range_insert(this->cend().get_ptr(), n, proxy); }

Again, let me know if you want me to create a ticket for this problem.