El 15/09/2014 15:29, Lars Hagström escribió:
Okay, I'm glad I asked, before we got further down that avenue... So, back to square one. Anyway, I've now just got checks at the beginning and end of priv_deallocate, and the checks do not fail. However, I did keep my logs in priv_check_and_allocate and priv_deallocate, and from my logs it looks like one block is deallocated twice. So my current theory is that there is something in the intrusive vector that causes a double deallocation. At the end of my email is the log and the call stack for this.
It seems that the code handling the backwards expansion of the buffer has a bug destroying an object twice. As a workaround, try to comment "expand_bwd" flags from allocator calls (Boost.Interprocess allocators support realloc-like buffer expansions where the new buffer can contain the old one). Example in "vector::priv_forward_range_insert_no_capacity": std::pair<pointer, bool> ret = (this->m_holder.allocation_command (allocate_new | expand_fwd | expand_bwd, this->m_holder.m_size + n, ...); Just leave "allocate_new | expand_fwd" (allocate new buffer or expand current one without moving the beginning). Backwards expansion is tested in Boost.Container but not the object construction/destruction count (I'll need to add this in my tests). If this workaround works for you, we'll delay the VM creation to see if I can see detect the problem improving Boost.Container tests. Best, Ion