Unit tests: Unreachable block in tests::test_main (panic hook)

[Duckilicious]

This isn't a compiler bug. But a "memory leak" in the unit tests main function that valgrind catches.
It's not a memory leak in the strict sense but a reachable block we never free and shows up in Valgrind summary.
I think it's better user experience if it won't be reported.

To reproduce you can do the following:

❯ cargo new reachable_block_with_cargo_test --lib
     Created library `reachable_block_with_cargo_test` package

gelbard in 🌐 ~/Projects took 41s
❯ cd reachable_block_with_cargo_test/

gelbard in 🌐 ~/Projects/reachable_block_with_cargo_test on  master [?]
❯ cargo test
   Compiling reachable_block_with_cargo_test v0.1.0 (/home/gelbard/Projects/reachable_block_with_cargo_test)
    Finished test [unoptimized + debuginfo] target(s) in 0.27s
     Running unittests src/lib.rs (target/debug/deps/reachable_block_with_cargo_test-912744a325bf7c5e)

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests reachable_block_with_cargo_test

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


gelbard in 🌐 ~/Projects/reachable_block_with_cargo_test on  master [?] took 22s
❯ /snap/bin/valgrind --leak-check=full --show-leak-kinds=all target/debug/deps/reachable_block_with_cargo_test-912744a325bf7c5e
==146594== Memcheck, a memory error detector
==146594== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==146594== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==146594== Command: target/debug/deps/reachable_block_with_cargo_test-912744a325bf7c5e
==146594==

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.09s

==146594==
==146594== HEAP SUMMARY:
==146594==     in use at exit: 16 bytes in 1 blocks
==146594==   total heap usage: 446 allocs, 445 frees, 61,882 bytes allocated
==146594==
==146594== 16 bytes in 1 blocks are still reachable in loss record 1 of 1
==146594==    at 0x4A390C5: malloc (vg_replace_malloc.c:442)
==146594==    by 0x151336: alloc (alloc.rs:98)
==146594==    by 0x151336: alloc_impl (alloc.rs:181)
==146594==    by 0x151336: allocate (alloc.rs:241)
==146594==    by 0x151336: exchange_malloc (alloc.rs:330)
==146594==    by 0x151336: new<test::test_main::{closure_env#0}> (boxed.rs:217)
==146594==    by 0x151336: test::test_main (lib.rs:124)
==146594==    by 0x1522F9: test::test_main_static (lib.rs:160)
==146594==    by 0x11E102: reachable_block_with_cargo_test::main (lib.rs:1)
==146594==    by 0x11EABA: core::ops::function::FnOnce::call_once (function.rs:250)
==146594==    by 0x11E76D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:154)
==146594==    by 0x11DFC0: std::rt::lang_start::{{closure}} (rt.rs:166)
==146594==    by 0x177D3A: call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (function.rs:284)
==146594==    by 0x177D3A: do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panicking.rs:504)
==146594==    by 0x177D3A: try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (panicking.rs:468)
==146594==    by 0x177D3A: catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panic.rs:142)
==146594==    by 0x177D3A: {closure#2} (rt.rs:148)
==146594==    by 0x177D3A: do_call<std::rt::lang_start_internal::{closure_env#2}, isize> (panicking.rs:504)
==146594==    by 0x177D3A: try<isize, std::rt::lang_start_internal::{closure_env#2}> (panicking.rs:468)
==146594==    by 0x177D3A: catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> (panic.rs:142)
==146594==    by 0x177D3A: std::rt::lang_start_internal (rt.rs:148)
==146594==    by 0x11DF99: std::rt::lang_start (rt.rs:165)
==146594==    by 0x11E12D: main (in /home/gelbard/Projects/reachable_block_with_cargo_test/target/debug/deps/reachable_block_with_cargo_test-912744a325bf7c5e)
==146594==
==146594== LEAK SUMMARY:
==146594==    definitely lost: 0 bytes in 0 blocks
==146594==    indirectly lost: 0 bytes in 0 blocks
==146594==      possibly lost: 0 bytes in 0 blocks
==146594==    still reachable: 16 bytes in 1 blocks
==146594==         suppressed: 0 bytes in 0 blocks
==146594==
==146594== For lists of detected and suppressed errors, rerun with: -s
==146594== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[bjorn3]

Did you explicitly pass --show-reachable=yes to valgrind? "Still reachable" blocks are not reported by default according to the manual as they are to quote the manual "very common and arguably not a problem".

[Duckilicious]

Nope, it also shows in the summary without any flags (without the backtrace) and not as an error.

I agree, this isn't a real problem most of the time. I find it a user experience issue more than it is a "bug". Unittests and tests in general are commonly used to find memory-leaks, the fact that such a common tool for this task will report a reachable block on any unittest ran by the default unittests launcher is misleading. Furthermore, for some test cases the user might want to know that they actually free the entire memory they allocated in the test, since it can have broader implication in the scope of an entire application.

Overall, since the fix here is also pretty easy I think we should just fix this.