Boost C++ Libraries: Ticket #8395: Valgrind error in lockfree::queue

attachment set

adam@… — Fri, 05 Apr 2013 13:04:58 GMT

attachment → lockfree.patch

Patch to correct valgrind issue (as applied to version 1.53)

adam@… — Fri, 05 Apr 2013 13:10:43 GMT

I've attached a patch (attachment:lockfree.patch ) that resolves the issue for me.

Note that this basically involves uncommenting the initialisation of the next pointer in the queue::node structure. However, it looks very much like the code relies on this being uninitialised - so this patch probably breaks something else.

timblechmann — Fri, 05 Apr 2013 13:25:00 GMT

i will have to review this specific part carefully. the uninitialized part is related to the ABA prevention counter, simply initializing it may silent the valgrind warning, but introduce an ABA problem, so this patch might break the data structure in a very subtle way.

this issue could possibly be considered as `false positive' and the better way to silence the warning, might be to initialize the memory region, not in the constructor, but when allocating memory from the OS.

might take me some time to review all the code ...

attachment set

adam@… — Fri, 05 Apr 2013 13:55:54 GMT

attachment → lockfree2.patch

Revised patch that uses a custom allocator to zero initialise nodes.

adam@… — Fri, 05 Apr 2013 13:57:37 GMT

Having delved a little further I concur, the patch was more of a confirmation for me of where the warning was coming from.

On further analysis:

The warning does not occur if the container is not given a size at construction:

boost::lockfree::queue<int*> q;

and appears to be caused by the allocation, but not construction, of all the nodes in the freelist class.

If I understand correctly, it doesn't matter that the next tag is uninitialised, the only important thing is that the new tag is different to the old tag for tags that reside at the same address - so in that sense, this is a false positive (and the patch is bad!).

One option would be to add a constructor or policy to the freelist class that caused it to zero initialise memory on allocation, or to use a custom allocator with the same behaviour, which I think would suppress the warning. I don't think this would cause any issues because the freelist doesn't do any "real" deallocation until destruction.

I've attached another patch (attachment:lockfree2.patch ) that implements the custom allocator strategy. Again, this appears to successfully suppress the valgrind warning, I can't say whether or not there are other unintended side effects though.

breese@… — Sat, 13 Sep 2014 13:47:35 GMT

I get the same valgrind report. Furthermore, I get a similar report if I change the queue to use boost::lockfree::capacity<128>.

I am not so sure that valgrind is reporting a false positive. An uninitialized value means that it could be any value, including the one that causes the ABA problem.

Unfortunately, applying the second patch to the develop branch does not make the reports disappear.

w.goesgens@… — Tue, 19 Jan 2016 16:11:20 GMT

Is there any news on this? The patches wouldn't fix it for me, and the noise in valgrind is really anoying...

anonymous — Mon, 12 Dec 2016 14:24:20 GMT

Same here.Valgrind outputs a 'Conditional jump or move depends on uninitialised value(s)' about it.

anonymous — Sun, 16 Apr 2017 05:31:19 GMT

Same here with boost 1.58. Compiled in debug with --track-origins=yes, I have:

==10410== Conditional jump or move depends on uninitialised value(s)
==10410==    at 0x401939: compare_exchange_weak (ops_gcc_atomic.hpp:132)
==10410==    by 0x401939: compare_exchange_weak (atomic_template.hpp:386)
==10410==    by 0x401939: compare_exchange_weak (atomic_template.hpp:393)
==10410==    by 0x401939: bool boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::do_push<false>(int* const&) (queue.hpp:307)
==10410==    by 0x400C48: boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::push(int* const&) (queue.hpp:267)
==10410==    by 0x4008DC: main (plap.cpp:9)
==10410==  Uninitialised value was created by a stack allocation
==10410==    at 0x40361E: boost::atomics::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> >::atomic() (atomic_template.hpp:680)