Boost logo

Boost :

Subject: Re: [boost] [intrusive] Possible bug in bstree_algorithms.hpp
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2014-09-15 17:36:22


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk