Tests sometimes leak around 50 bytes

Code

Edit: the initial bug was found on nightly but it replicates on stable on a less up-to-date machine, see below

Similar to #135608 but not the same stack trace

$ cargo install cargo-valgrind 
$ cargo new valgrind-fails

add blank test in src/main.rs:

fn main() {
    println!("Hello, world!");
}

#[cfg(test)]
mod tests {
    #[test]
    pub fn hmm() {}
}


$ cargo +nightly valgrind test -r

Current output

Error leaked 48 B in 1 block
        Info stack trace (user code at the bottom)
             at malloc
             at std::thread::Thread::new
             at std::thread::current::init_current
             at std::sync::mpmc::context::Context::new
             at std::sys::thread_local::native::lazy::Storage<T,D>::initialize
             at std::sync::mpmc::list::Channel<T>::recv
             at test::console::run_tests_console
             at test::test_main
             at test::test_main_static
             at std::sys::backtrace::__rust_begin_short_backtrace
             at std::rt::lang_start::{{closure}}
             at std::rt::lang_start_internal
     Summary Leaked 48 B total (0 other errors)
error: test failed, to rerun pass `--bin valgrind-fails`

Desired output

Happy valgrind

Rationale and extra context

No response

Other cases

Rust Version

$ rustc --version --verbose
rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.84.0
LLVM version: 19.1.5

Anything else?

I have

cargo 1.84.0 (66221abde 2024-11-19)
valgrind-3.18.1
Ubuntu 22.04.5 LTS (not checked on other OSes)

On another machine, nightly works fine but stable sporadically fails in debug mode:

$ cargo valgrind test 
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.03s
     Running unittests src/main.rs (target/debug/deps/vaaa-a01420ed07e277c8)

running 1 test
test tests::hmm ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.08s

       Error leaked 56 B in 1 block
        Info stack trace (user code at the bottom)
             at malloc (vg_replace_malloc.c:446)
             at alloc (alloc.rs:99)
             at alloc_impl (alloc.rs:192)
             at allocate (alloc.rs:254)
             at {closure#0}<std::thread::Inner> (sync.rs:483)
             at allocate_for_layout<core::mem::maybe_uninit::MaybeUninit<std::thread::Inner>, alloc::sync::{impl#14}::new_uninit::{closure_env#0}<std::thread::Inner>, fn(*mut u8) -> *mut alloc::sync::ArcInner<core::mem::maybe_uninit::MaybeUninit<std::thread::Inner>>> (sync.rs:1925)
             at new_uninit<std::thread::Inner> (sync.rs:481)
             at new_inner (mod.rs:1343)
             at new_main (mod.rs:1333)
             at init (rt.rs:113)
             at {closure#0} (rt.rs:172)
             at do_call<std::rt::lang_start_internal::{closure_env#0}, ()> (panicking.rs:557)
             at try<(), std::rt::lang_start_internal::{closure_env#0}> (panicking.rs:520)
             at catch_unwind<std::rt::lang_start_internal::{closure_env#0}, ()> (panic.rs:358)
             at std::rt::lang_start_internal (rt.rs:172)
             at std::rt::lang_start (rt.rs:194)
             at main
     Summary Leaked 56 B total (0 other errors)
error: test failed, to rerun pass `--bin vaaa`

Caused by:
  process didn't exit successfully: `/home/matrix/.cargo/bin/cargo-valgrind /home/matrix/Documents/vaaa/target/debug/deps/vaaa-a01420ed07e277c8` (exit status: 127)
note: test exited abnormally; to see the full output pass --nocapture to the harness.

rustc 1.83.0 (90b35a6 2024-11-26)
binary: rustc
commit-hash: 90b35a6
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

I think this is basically the same issue as #135608. I submitted my issue after minimizing precisely your reproducer.

If it is, the proposed solution is not really satisfying to me — not being able to rely on valgrinds return code for proper test CI is quite bothering.

If it is, the proposed solution is not really satisfying to me — not being able to rely on valgrinds return code for proper test CI is quite bothering.

You can use --errors-for-leak-kinds=definite to stop it being a bother.

The proposed solution seems to be "wait for #134085 to be merged". Personally, I'm fine with that. I pinned my valgrind CI to beta for now due to this.

You can use --errors-for-leak-kinds=definite to stop it being a bother.

Sure, that sort of works. But it does modify the behavior of valgrind, I'm telling it not to report to me everything it sees as it did before the regression, so that I can hide the fact that Rust itself leaks memory when it decides to (and not deterministically).

This will work as a patch, but it doesn't feel very pleasing, philosophically speaking. I do want to see every leak, but I also would like an empty cargo project to work on valgrind without tweaks.

But again, this is bleeding edge, I can live with it.

The proposed solution seems to be "wait for #134085 to be merged".

Fine by me!

Closing as duplicate

suppression for thread_local::native::lazy::Storage<>::get_or_init_sl…

ci: suppress rust std lib memory leak

Navigation Menu

Repository navigation

Tests sometimes leak around 50 bytes #135628

Code

Current output

Desired output

Rationale and extra context

Other cases

Rust Version

Anything else?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tests sometimes leak around 50 bytes #135628

Description

Code

Current output

Desired output

Rationale and extra context

Other cases

Rust Version

Anything else?

Activity

MRandl commented on Jan 17, 2025

purplesyringa commented on Jan 17, 2025

MRandl commented on Jan 17, 2025

ChrisDenton commented on Jan 17, 2025

purplesyringa commented on Jan 17, 2025

MRandl commented on Jan 17, 2025

MRandl commented on Jan 17, 2025

MRandl commented on Jan 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions