Valgrind full leak check reports a leak on Rust 1.83.0

[sharksforarms]

Hi all, creating this issue as I noticed our CI failing due to valgrind when updating from 1.82.0 to 1.83.0, the leak seems to be from rust and not from the application (reproducible with default cargo new --bin). Others may also hit this.

Code

# cargo new --bin testvalgrind

$ cat rust-toolchain.toml
[toolchain]
channel = "1.82.0"

$ cargo build && valgrind --leak-check=full target/debug/testvalgrind
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s
==1002693== Memcheck, a memory error detector
==1002693== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1002693== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==1002693== Command: target/debug/testvalgrind
==1002693==
Hello, world!
==1002693==
==1002693== HEAP SUMMARY:
==1002693==     in use at exit: 0 bytes in 0 blocks
==1002693==   total heap usage: 10 allocs, 10 frees, 3,184 bytes allocated
==1002693==
==1002693== All heap blocks were freed -- no leaks are possible
==1002693==
==1002693== For lists of detected and suppressed errors, rerun with: -s
==1002693== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

---

$ cat rust-toolchain.toml
[toolchain]
channel = "1.83.0"

$ cargo build && valgrind --leak-check=full target/debug/testvalgrind
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s
==1002883== Memcheck, a memory error detector
==1002883== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1002883== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==1002883== Command: target/debug/testvalgrind
==1002883==
Hello, world!
==1002883==
==1002883== HEAP SUMMARY:
==1002883==     in use at exit: 56 bytes in 1 blocks
==1002883==   total heap usage: 9 allocs, 8 frees, 3,152 bytes allocated
==1002883==
==1002883== 56 bytes in 1 blocks are possibly lost in loss record 1 of 1
==1002883==    at 0x4848853: malloc (vg_replace_malloc.c:381)
==1002883==    by 0x1290D0: std::rt::lang_start_internal (alloc.rs:99)
==1002883==    by 0x10EA19: std::rt::lang_start (rt.rs:194)
==1002883==    by 0x10E9DD: main (in /tmp/testvalgrind/target/debug/testvalgrind)
==1002883==
==1002883== LEAK SUMMARY:
==1002883==    definitely lost: 0 bytes in 0 blocks
==1002883==    indirectly lost: 0 bytes in 0 blocks
==1002883==      possibly lost: 56 bytes in 1 blocks
==1002883==    still reachable: 0 bytes in 0 blocks
==1002883==         suppressed: 0 bytes in 0 blocks
==1002883==
==1002883== For lists of detected and suppressed errors, rerun with: -s
==1002883== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

I expected to see this happen: valgrind reports no leak

Instead, this happened: valgrind reports a leak

Version it worked on

It most recently worked on: Rust 1.82.0

Version with regression

rustc --version --verbose:

rustc 1.83.0 (90b35a623 2024-11-26)

[ChrisDenton]

This is almost certainly a deliberate leak. You seem to be using a fairly old version of valgrind. It's quite possible a newer version would recognise it's not a leak.

[sharksforarms]

This is almost certainly a deliberate leak.

looks like it could be, reported in case it isn't (different behavior than 1.82.0)

You seem to be using a fairly old version of valgrind. It's quite possible a newer version would recognise it's not a leak.

the latest valgrind gives us more info

$ ./valgrind-3.24.0/inst/bin/valgrind --leak-check=full target/debug/testvalgrind
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
==1037298== Memcheck, a memory error detector
==1037298== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==1037298== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==1037298== Command: target/debug/testvalgrind
==1037298==
Hello, world!
==1037298==
==1037298== HEAP SUMMARY:
==1037298==     in use at exit: 56 bytes in 1 blocks
==1037298==   total heap usage: 9 allocs, 8 frees, 3,152 bytes allocated
==1037298==
==1037298== 56 bytes in 1 blocks are possibly lost in loss record 1 of 1
==1037298==    at 0x484880F: malloc (vg_replace_malloc.c:446)
==1037298==    by 0x1290D0: alloc (alloc.rs:99)
==1037298==    by 0x1290D0: alloc_impl (alloc.rs:192)
==1037298==    by 0x1290D0: allocate (alloc.rs:254)
==1037298==    by 0x1290D0: {closure#0}<std::thread::Inner> (sync.rs:483)
==1037298==    by 0x1290D0: 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)
==1037298==    by 0x1290D0: new_uninit<std::thread::Inner> (sync.rs:481)
==1037298==    by 0x1290D0: new_inner (mod.rs:1343)
==1037298==    by 0x1290D0: new_main (mod.rs:1333)
==1037298==    by 0x1290D0: init (rt.rs:113)
==1037298==    by 0x1290D0: {closure#0} (rt.rs:172)
==1037298==    by 0x1290D0: do_call<std::rt::lang_start_internal::{closure_env#0}, ()> (panicking.rs:557)
==1037298==    by 0x1290D0: try<(), std::rt::lang_start_internal::{closure_env#0}> (panicking.rs:520)
==1037298==    by 0x1290D0: catch_unwind<std::rt::lang_start_internal::{closure_env#0}, ()> (panic.rs:358)
==1037298==    by 0x1290D0: std::rt::lang_start_internal (rt.rs:172)
==1037298==    by 0x10EA19: std::rt::lang_start (rt.rs:194)
==1037298==    by 0x10E9DD: main (in /tmp/testvalgrind/target/debug/testvalgrind)
==1037298==
==1037298== LEAK SUMMARY:
==1037298==    definitely lost: 0 bytes in 0 blocks
==1037298==    indirectly lost: 0 bytes in 0 blocks
==1037298==      possibly lost: 56 bytes in 1 blocks
==1037298==    still reachable: 0 bytes in 0 blocks
==1037298==         suppressed: 0 bytes in 0 blocks
==1037298==
==1037298== For lists of detected and suppressed errors, rerun with: -s
==1037298== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[lnicola]

This actually seems to be fixed in beta, so I think it's a 1.83 regression. It seemed a bit annoying to deal with because I only noticed it in the unit test runner (cargo test in a binary crate), which is hard to pick on CI, and my local suppression didn't work on GHA.

EDIT, since that probably didn't make sense: we're using cargo-valgrind on CI, which uses a socket to talk to valgrind, and VALGRINDFLAGS="--gen-suppressions=all doesn't do anything. Running valgrind by hand works, but for unit tests the binary path is harder to find.

[lqd]

Can you cargo-bisect-rustc the PR that fixed it, to see if we'd like to backport it?

[workingjubilee]

According to lnicola, this is fixed on beta.

[workingjubilee]

As discussed regarding intentional "leaks", "valgrind reports a leak" does not mean "a memory leak occurred". There are many APIs in the standard library that create a small, permanent allocation, and then deliberately defer collection of that memory to process exit. They do not grow. A memory leak, as far as we are concerned, is unbounded memory usage, and this is not.

And this is already fixed, so.

Closing.