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