Skip to content

Tests sometimes leak around 50 bytes #135628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
MRandl opened this issue Jan 17, 2025 · 8 comments
Closed

Tests sometimes leak around 50 bytes #135628

MRandl opened this issue Jan 17, 2025 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@MRandl
Copy link

MRandl commented Jan 17, 2025

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)
@MRandl MRandl added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 17, 2025
@MRandl
Copy link
Author

MRandl commented Jan 17, 2025

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

@MRandl MRandl changed the title Nightly tests leak 48B systematically Tests sometimes leak around 50 bytes Jan 17, 2025
@purplesyringa
Copy link
Contributor

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

@MRandl
Copy link
Author

MRandl commented Jan 17, 2025

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.

@ChrisDenton
Copy link
Member

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.

@purplesyringa
Copy link
Contributor

purplesyringa commented Jan 17, 2025

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.

@MRandl
Copy link
Author

MRandl commented Jan 17, 2025

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.

@MRandl
Copy link
Author

MRandl commented Jan 17, 2025

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

Fine by me!

@MRandl
Copy link
Author

MRandl commented Jan 17, 2025

Closing as duplicate

@MRandl MRandl closed this as completed Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants