There are 32 bytes leaked out of some internal runtime code, but they are allocated once globally, not "whenever a thread closes".
The code that generated the allocation that leaked in that issue (std::io::with_task_stdout) no longer exists, and I believe the thread local storage system has been rewritten since then as well. Could you clarify how that issue is relevant to modern Rust?
I'm following up on this since the person you were writing in response to has deleted their comments.
Alex Crichton, one of Rust's top contributors, confirmed that the problem is still present a day ago. He acknowledged this on one of the very issues the original comment was in reference to.
alexcrichton commented a day ago
@huonw did you test on linux? You may have been using the ELF TLS instead of pthread tls. I just built a compiler with --disable-elf-tls and it looks like the leak is still present:
$ valgrind ./foo
==21255== Memcheck, a memory error detector
==21255== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21255== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==21255== Command: ./foo
==21255==
Hello World!
How are you today
==21255==
==21255== HEAP SUMMARY:
==21255== in use at exit: 312 bytes in 7 blocks
==21255== total heap usage: 26 allocs, 19 frees, 2,720 bytes allocated
==21255==
==21255== LEAK SUMMARY:
==21255== definitely lost: 0 bytes in 0 blocks
==21255== indirectly lost: 0 bytes in 0 blocks
==21255== possibly lost: 0 bytes in 0 blocks
==21255== still reachable: 312 bytes in 7 blocks
==21255== suppressed: 0 bytes in 0 blocks
==21255== Rerun with --leak-check=full to see details of leaked memory
==21255==
==21255== For counts of detected and suppressed errors, rerun with: -v
==21255== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
It's exceptionally too bad the person who originally pointed this out in the comments here felt the need to delete their comment.
I'm getting mixed signals. In the comment elsewhere you say the original poster linked #14875, but here you refer to #19776. It's also the case that #19776 isn't even a problem, because using "leak" here is a misnomer. The "still reachable" section doesn't indicate memory that was leaked, but memory that could have been freed but that nobody bothered to. And the reason that this isn't a problem is because failing to explicitly free memory during process exit doesn't matter because the act of exiting will free that memory by definition. There's no leak here; the only reason that issue exists is because it makes the valgrind output slightly annoying when run with certain settings. It's a tooling issue, not a language issue.
