[interprocess] Strange behaviour after push_back in a b::i::vector of b::i::weak_ptr
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
On 19.7.2012 16:07, Gaetan Gaumer wrote:
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.
Hi. As you are using IPC (and the sample code doesn't actually reproduce the problem, as you said), I'm assuming you running that particular piece of code in a multi-thread/process environment (and did see some pthread traces there). If so, you've simply forgotten to add a synchronization mechanism to your code. Multiple writers, multiple readers; Things like that happen as the code is not executed atomically and the other process (or thread) happens to write data to vector between the push_back() and rbegin(). Perhaps the resize operation happens to take so much time, that it only happens then. If my guess was correct, simply (allocate a shared mutex, ) acquire an exclusive lock when you are writing and a sharable lock if you're only reading data. -- Pekka
2012/7/19 Pekka Seppänen
On 19.7.2012 16:07, Gaetan Gaumer wrote:
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.
Hi.
As you are using IPC (and the sample code doesn't actually reproduce the problem, as you said), I'm assuming you running that particular piece of code in a multi-thread/process environment (and did see some pthread traces there).
We do are in a multi-thread/multi-process environment but in this particular case, this vector is filled by only one thread in one process. The commented trace was here only to be sure of that.
If so, you've simply forgotten to add a synchronization mechanism to your code. Multiple writers, multiple readers; Things like that happen as the code is not executed atomically and the other process (or thread) happens to write data to vector between the push_back() and rbegin().
Perhaps the resize operation happens to take so much time, that it only happens then. If my guess was correct, simply (allocate a shared mutex, ) acquire an exclusive lock when you are writing and a sharable lock if you're only reading data.
I already thought about it but that's not the case here, all our calls to addData() are already protected by some interprocess mutexes and interthread mutexes which work well with other structures. -- Pekka
Cheers, Gaëtan
El 19/07/2012 15:07, Gaetan Gaumer escribió:
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.
This seems a bug. Can you please fill a ticket with a test case so that this is not forgotten? Thanks, Ion
El 19/07/2012 20:25, Ion Gaztañaga escribió:
El 19/07/2012 15:07, Gaetan Gaumer escribió:
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.
This seems a bug. Can you please fill a ticket with a test case so that this is not forgotten?
Maybe you could try a more recent interprocess code to check if the bug is still there. Best, Ion
2012/7/19 Ion Gaztañaga
El 19/07/2012 20:25, Ion Gaztañaga escribió:
El 19/07/2012 15:07, Gaetan Gaumer escribió:
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.
This seems a bug. Can you please fill a ticket with a test case so that this is not forgotten?
Maybe you could try a more recent interprocess code to check if the bug is still there.
I'm trying with v1.50 and will fill a bug report if the bug is still here. Meanwhile, can I ask you to look at another interprocess::vector and intreprocess::weak_ptr potential problem I asked about several month ago ? http://lists.boost.org/boost-users/2010/11/64591.php Nobody answered my question and I still have the same problem in V1.47 and V1.50 Thanks for your help and all your great work. Gaëtan
Nobody answered my question and I still have the same problem in V1.47 and V1.50
Thanks for your help and all your great work. Gaëtan
This seems a bug. Please put this issue also in the same bug report so I don't forget it. I hope next month I'll have some time to resolve several pending bugs. Best, Ion
2012/7/23 Ion Gaztañaga
Nobody answered my question and I still have the same problem in V1.47
and V1.50
Thanks for your help and all your great work. Gaëtan
This seems a bug. Please put this issue also in the same bug report so I don't forget it. I hope next month I'll have some time to resolve several pending bugs.
Best,
Ion
I created the bug report : https://svn.boost.org/trac/boost/ticket/7164 I hope I included all the information needed. Good luck with these ones. Cheers, Gaëtan
El 24/07/2012 11:00, Gaetan Gaumer escribió:
I created the bug report : https://svn.boost.org/trac/boost/ticket/7164 I hope I included all the information needed. Good luck with these ones.
Thanks, Ion
participants (3)
-
Gaetan Gaumer -
Ion Gaztañaga -
Pekka Seppänen