Skip to content

Valgrind reports a leak of 32 Bytes for a std::thread. #71616

New issue

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

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

Already on GitHub? # to your account

Closed
RustProfi opened this issue Apr 27, 2020 · 5 comments
Closed

Valgrind reports a leak of 32 Bytes for a std::thread. #71616

RustProfi opened this issue Apr 27, 2020 · 5 comments
Labels
C-bug Category: This is a bug.

Comments

@RustProfi
Copy link

I tried this code:

use std::thread;
fn main() {
    thread::spawn(|| println!("Hello, world!")).join().unwrap();
}

The code compiles and Hello, world! gets printed as expected but valgrind reports a leak of still reachable 32 Bytes:

==8853== Memcheck, a memory error detector
==8853== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8853== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==8853== Command: ./target/release/thread_test
==8853== 
Hello, world!
==8853== 
==8853== HEAP SUMMARY:
==8853==     in use at exit: 32 bytes in 1 blocks
==8853==   total heap usage: 30 allocs, 29 frees, 4,048 bytes allocated
==8853== 
==8853== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
==8853==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8853==    by 0x4E3D7E4: _dlerror_run (dlerror.c:140)
==8853==    by 0x4E3D165: dlsym (dlsym.c:70)
==8853==    by 0x1178B2: fetch (weak.rs:61)
==8853==    by 0x1178B2: get<unsafe extern "C" fn(*const libc::unix::linux_like::linux::gnu::b64::x86_64::pthread_attr_t) -> usize> (weak.rs:46)
==8853==    by 0x1178B2: min_stack_size (thread.rs:439)
==8853==    by 0x1178B2: std::sys::unix::thread::Thread::new (thread.rs:51)
==8853==    by 0x10C8DD: std::thread::spawn (in /home/thread_test/target/release/thread_test)
==8853==    by 0x10CE5F: thread_test::main (in /home/thread_test/target/release/thread_test)
==8853==    by 0x10C682: std::rt::lang_start::{{closure}} (in /home/thread_test/target/release/thread_test)
==8853==    by 0x116122: {{closure}} (rt.rs:52)
==8853==    by 0x116122: std::panicking::try::do_call (panicking.rs:303)
==8853==    by 0x118446: __rust_maybe_catch_panic (lib.rs:86)
==8853==    by 0x116B2B: try<i32,closure-0> (panicking.rs:281)
==8853==    by 0x116B2B: catch_unwind<closure-0,i32> (panic.rs:394)
==8853==    by 0x116B2B: std::rt::lang_start_internal (rt.rs:51)
==8853==    by 0x10CEE1: main (in /home/thread_test/target/release/thread_test)
==8853== 
==8853== LEAK SUMMARY:
==8853==    definitely lost: 0 bytes in 0 blocks
==8853==    indirectly lost: 0 bytes in 0 blocks
==8853==      possibly lost: 0 bytes in 0 blocks
==8853==    still reachable: 32 bytes in 1 blocks
==8853==         suppressed: 0 bytes in 0 blocks
==8853== 
==8853== For counts of detected and suppressed errors, rerun with: -v
==8853== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Meta

rustc --version --verbose:

rustc 1.43.0 (4fb7144ed 2020-04-20)
binary: rustc
commit-hash: 4fb7144ed159f94491249e86d5bbd033b5d60550
commit-date: 2020-04-20
host: x86_64-unknown-linux-gnu
release: 1.43.0
LLVM version: 9.0
Backtrace

Since the code runs, there is no backtrace :)

@RustProfi RustProfi added the C-bug Category: This is a bug. label Apr 27, 2020
@RustProfi RustProfi changed the title Valgrind reports a leak of 32 Bytes for a simple thread. Valgrind reports a leak of 32 Bytes for a std::thread. Apr 27, 2020
@jonas-schievink
Copy link
Contributor

cc #19776 / #28129

@tesuji
Copy link
Contributor

tesuji commented Apr 28, 2020

Maybe updating to latest valgrind (3.15) helps.

@RustProfi
Copy link
Author

RustProfi commented Apr 28, 2020

Maybe updating to latest valgrind (3.15) helps.

I just compiled a 3.15 version of valgrind and it did not make any change :/

@tesuji
Copy link
Contributor

tesuji commented Apr 29, 2020

Cannot reproduce. I have llvm-10, valgrind-3.15, rustc 1.44.0-nightly (b2e36e6 2020-04-22)
on x86 linux gnu machine.

@Mark-Simulacrum
Copy link
Member

Hm, my guess is that this is not reproducible on systems that do have __pthread_get_minstack -- but if you don't, then calling dlsym will return an error which isn't cleared -- indeed, I can't see an API to do so. Presumably that's the cause of the "bug" here.

AFAICT, we can't do anything about the leak anyway -- there's no API to clear the error. With that in mind, I'm going to close since it seems like we can't do anything about this.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

4 participants