Hello all,
I was just in the process of doing vagrind runs on a server process that
recently switched to an architecture using boost fibers. Specifically
buffered_channel as a number of worker fibers run in a thread.
The process was regularily checked with valgrind before but now I'm getting
overwhelmed by the amount of messages. Uninitialized values, invalid writes
and reads all across the board and all seem to come out of fibers. I see no
direct mention of my code.
A few samples:
==8024== Thread 1:
==8024== Conditional jump or move depends on uninitialised value(s)
==8024== at 0x454F98: unique (circular_list_algorithms.hpp:112)
==8024== by 0x454F98: empty (list.hpp:540)
==8024== by 0x454F98: boost::fibers::buffered_channel >::close() (buffered_channel.hp
==8024== by 0x454FDB: boost::fibers::buffered_channel >::~buffered_channel() (buffere
==8024== by 0x4376BF: operator() (unique_ptr.h:78)
==8024== Invalid read of size 8
==8024== at 0x9C1756: boost::fibers::context::~context() (in /my_server)
==8024== by 0x9C31CF: boost::fibers::main_context::~main_context() (in
/my_server)
==8024== by 0x6B0B85E: __call_tls_dtors (in /usr/lib64/libc-2.26.so)
==8024== by 0x5D49558: start_thread (in /usr/lib64/libpthread-2.26.so)
==8024== by 0x6BC92FE: clone (in /usr/lib64/libc-2.26.so)
==8024== Address 0xa6f0010 is 32 bytes inside a block of size 232 alloc'd
==8024== at 0x4C2D1DA: operator new(unsigned long)
(vg_replace_malloc.c:334)
and thousands more similar to this. Now, is there something about fibers
that causes this as false positives (such as valgrind not knowing about
fibers or coroutines) or is there an underlying problem here?
This is running on AWS Linux 2, built with gcc 7.3, boost 1.69.
Multithreaded release build with debug info. Nothing out of the ordinary.
I am a bit concerned about this and wanted to let the list know. Can
provide more output on demand.
Cheers,
Stephan
