[Boost-users] [interprocess] Strange behaviour after push_back in a b::i::vector of b::i::weak_ptr

Subject: [Boost-users] [interprocess] Strange behaviour after push_back in a b::i::vector of b::i::weak_ptr
From: Gaetan Gaumer (gaetan.gaumer_at_[hidden])
Date: 2012-07-19 09:07:10

Hello Ion a others interprocess guru,
I'm currently using an interprocess::vector storing intreprocess::weak_ptr
to data.
Sometimes after adding a shared_ptr to my vector with push_back, the
weak_ptr stored at the end of the vector is not
the one I just inserted, but a copy of a previously inserted weak_ptr.

For examples the code below :
void addData (const SharableDataTypes<Data>::SharedPtrType & PData){
 dataWPVector.push_back(PData);
if (dataWPVector.rbegin()->lock()->getObjectId() != PData->getObjectId()){
 std::cerr << "After pushback in dataWPVector vector last elem Id=" <<
 dataWPVector.rbegin()->lock()->getObjectId()
                         << " added cable Id =" << PData->getObjectId() <<
std::endl;
}
}

spills the trace :
"After pushback in  dataWPVector  vector last elem Id=50332165 added elem
Id =352322053"
which should obviously not happen.

By adding some traces to the file
 : boost/interprocess/containers/container/vector.hpp
I found that this case only happens during a resizing step when the
method priv_range_insert_expand_backwards is used
and in one of the 8 cases I labeled "4/8 and NOT do_after" (see
http://pastebin.com/bLBwiBia line 41)

For easier test, I created a sample code which try to reproduce the problem
: http://pastebin.com/rdpZA7CU
(Note : I used multiIndex to be the closest to our code).

I compiled it with gcc44 (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6) on a 64b
 Red Hat Enterprise Linux Server release 5.4 server
using Boost V1.47 with the command :
gcc44 -std=c++0x -m64 -I/path_to_boot/boost_1_47_0/include/ -lrt -lstdc++
testPushBackVector.cc -o testPushBackVector

Note that this program does not reproduce the problem, as when it runs,
only the priv_range_insert_new_allocation method is called.
I don't know how to force the program to
use priv_range_insert_expand_backwards to reproduce the problem.

So now, the question : Am I doing something wrong or is this a bug ?
Thanks for your help,
Gaëtan