Vitali Lovich

That `/usr/local/` location of the cargo registry is super weird. Isn't that usually in the home directory? I suspect the problem is something weird within your Docker. One workaround (if...

I'm not sure I follow the explanation about the second case. You're saying the completion event comes back but the kernel keeps using the referenced buffer? I'm sure I'm understanding...

I wonder if there's some subtle race condition in the events where if the timing happens just right, even non-valgrind would hang.

Added some instrumentation into glommio `join`. Successful run without valgrind: ``` Started thread 1 glommio: Connecting receiver Started thread 2 glommio: Connecting peer glommio: Peer connected glommio: Receiver connected glommio:...

Interesting. On a recent run where I added even more instrumentation: shared_channel.rs (290): ``` pub async fn send(&self, item: T) -> Result { println!("{} Waiting for room to send...", self.id);...

Finally thread 2 hangs at: ``` #0 core::sync::atomic::atomic_load () at library/core/src/sync/atomic.rs:2961 #1 core::sync::atomic::AtomicU32::load () at library/core/src/sync/atomic.rs:2075 #2 std::sys::unix::locks::futex_mutex::Mutex::spin () at library/std/src/sys/unix/locks/futex_mutex.rs:70 #3 std::sys::unix::locks::futex_mutex::Mutex::lock_contended () at library/std/src/sys/unix/locks/futex_mutex.rs:61 #4 0x00000000003fbcdc in std::sys::unix::locks::futex_mutex::Mutex::lock...

When I run valgrind with drd, it starts with a complaint about latch and then a bunch of other data race warnings follow: https://gist.github.com/vlovich/b553ce3a2450907b62b135e3bdf8038c. Helgrind has similar complaints: https://gist.github.com/vlovich/4162aefdaaa8dc4a477431d1f44fab5c

I suspect these are false positives though. @glommer any thoughts here?

Btw I tried `--fair-sched=yes` and it's still hanging which is the only thing I've found about valgrind. Maybe I should open a bug upstream...

Filed upstream too just in case https://bugs.kde.org/show_bug.cgi?id=463859.