Closed
Description
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)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
MRandl commentedon Jan 17, 2025
On another machine, nightly works fine but stable sporadically fails in debug mode:
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
[-]Nightly tests leak 48B systematically[/-][+]Tests sometimes leak around 50 bytes[/+]purplesyringa commentedon Jan 17, 2025
I think this is basically the same issue as #135608. I submitted my issue after minimizing precisely your reproducer.
MRandl commentedon 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 commentedon Jan 17, 2025
You can use
--errors-for-leak-kinds=definite
to stop it being a bother.purplesyringa commentedon 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 commentedon Jan 17, 2025
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 commentedon Jan 17, 2025
Fine by me!
MRandl commentedon Jan 17, 2025
Closing as duplicate
suppression for thread_local::native::lazy::Storage<>::get_or_init_sl…
ci: suppress rust std lib memory leak
1 remaining item