Created attachment 168407 [details] Rust project reproducing the issue. SUMMARY Do some reads of a file with glommio & accessing the returned buffer causes valgrind to complain that the data is uninitialized. My hunch is that valgrind doesn't know to mark buffers filled by io_uring as defined. STEPS TO REPRODUCE 1. Unzip the attached zipfile 2. cd repro 3. cargo build 4. valgrind target/debug/repro OBSERVED RESULT Valgrind has a false-positive complaint that the returned read buffer has uninitialized data. ``` ==2943183== Conditional jump or move depends on uninitialised value(s) ==2943183== at 0x144540: <usize as core::iter::traits::accum::Sum>::sum::{{closure}} (accum.rs:53) ==2943183== by 0x15033D: core::iter::adapters::map::map_fold::{{closure}} (map.rs:89) ==2943183== by 0x150664: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold (macros.rs:232) ==2943183== by 0x150277: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold (map.rs:129) ==2943183== by 0x1444C6: <usize as core::iter::traits::accum::Sum>::sum (accum.rs:50) ==2943183== by 0x1502B2: core::iter::traits::iterator::Iterator::sum (iterator.rs:3642) ==2943183== by 0x1454B5: repro::main::{{closure}} (main.rs:17) ==2943183== by 0x146F25: glommio::task::raw::RawTask<F,R,S>::run (raw.rs:469) ==2943183== by 0x1DC63F: glommio::task::task_impl::Task::run (task_impl.rs:125) ==2943183== by 0x200FAF: glommio::executor::LocalExecutor::run_one_task_queue (mod.rs:1382) ==2943183== by 0x20059A: glommio::executor::LocalExecutor::run_task_queues (mod.rs:1330) ==2943183== by 0x141379: glommio::executor::LocalExecutor::run::{{closure}} (mod.rs:1483) ==2943183== ==2943183== Conditional jump or move depends on uninitialised value(s) ==2943183== at 0x145518: repro::main::{{closure}} (main.rs:18) ==2943183== by 0x146F25: glommio::task::raw::RawTask<F,R,S>::run (raw.rs:469) ==2943183== by 0x1DC63F: glommio::task::task_impl::Task::run (task_impl.rs:125) ==2943183== by 0x200FAF: glommio::executor::LocalExecutor::run_one_task_queue (mod.rs:1382) ==2943183== by 0x20059A: glommio::executor::LocalExecutor::run_task_queues (mod.rs:1330) ==2943183== by 0x141379: glommio::executor::LocalExecutor::run::{{closure}} (mod.rs:1483) ==2943183== by 0x141901: glommio::executor::LocalExecutor::run::{{closure}} (mod.rs:1518) ==2943183== by 0x148D00: scoped_tls::ScopedKey<T>::set (lib.rs:137) ==2943183== by 0x140BCD: glommio::executor::LocalExecutor::run (mod.rs:1518) ==2943183== by 0x145C23: repro::main (main.rs:4) ==2943183== by 0x14D8CA: core::ops::function::FnOnce::call_once (function.rs:250) ==2943183== by 0x14E3AD: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:155) ``` EXPECTED RESULT The data is initialized. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.8.1 (available in About System) KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION valgrind --version valgrind-3.23.0.GIT (valgrind-git-3.22.0.r243.g94e826519-1)
> My hunch is that valgrind doesn't know to mark buffers filled by io_uring as defined. I prefer to understand the code and use a debugger to see what is actually happening. > Valgrind has a false-positive complaint that the returned read buffer has uninitialized data. Wow. It's Rust, it must be right, is that it? Strangely I'm not too motivated to investigate this.
I'm not saying it's a false positive because Rust can't have uninitialized memory. I'm saying it's a false positive because the buffer comes back initialized with the data from disk & internally that buffer is coming from a buffer pool so it can't be some kind of use-after-free bug within the code itself (not to mention that the error from valgrind would be different).