Improve memory leak identification

[Firstyear]

Miri is able to determine if memory leaks occur. The output is similar to:

running 10 tests
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_1 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_2 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_3 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_4 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_5 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_1 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_2 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_3 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_4 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_5 ... ok

test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured; 175 filtered out

The following memory was leaked:
alloc876074 (Rust heap, size: 120, align: 8) {
    0x00 │ 07 00 00 00 00 00 00 20 0a 00 00 00 00 00 00 00 │ ....... ........
    0x10 │ 0b 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 │ ................
    0x20 │ 0d 00 00 00 00 00 00 00 0e 00 00 00 00 00 00 00 │ ................
    0x30 │ 0f 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 │ ................
    0x40 │ 0a 00 00 00 00 00 00 00 0b 00 00 00 00 00 00 00 │ ................
    0x50 │ 0c 00 00 00 00 00 00 00 0d 00 00 00 00 00 00 00 │ ................
    0x60 │ 0e 00 00 00 00 00 00 00 0f 00 00 00 00 00 00 00 │ ................
    0x70 │ 10 00 00 00 00 00 00 00                         │ ........
}
... <many more leaks below>

The leaks are not associated to a specific test however. To aid leak isolation, it would be good if there was a way to see which test caused what leak.

Some ideas are potentially to have a test function associated with the leak line like:

alloc876074 (collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_4) (Rust heap, size: 120, align: 8) {

Another option is to have bisection, so that when warnings or errors are omitted that the warnings can be traced to a minimum set of tests that create those errors.

Thanks!

[oli-obk]

We can't really do this in miri, this would need to be a test-suite feature in the official rust test suite.

What we can do is offer functions that you call at the beginning and end of a test and that record the set of allocations that are live and tell you what new allocations still exist at the second call.

[RalfJung]

We could also (optionally) capture (parts of) the stack trace for each allocation; that could be sufficient here. The performance impact could be really bad though.

[oli-obk]

cc #17

[Firstyear]

I would be quite happy with functions you can call at the start and end of tests to help you identify memory leaks better.

[RalfJung]

bevyengine/bevy#4959 contains a very nice snippet that helps identify which test in a test suite is leaking:

cargo --quiet test --lib -- --list | sed 's/: test$//' | xargs -n1 cargo miri test --lib -- --exact

[kryptan]

Would it be possible to detect leaks as they happen, that is as soon as the last pointer to the allocation goes out of scope?

[oli-obk]

No that's not possible. You could have turned a pointer into a [bool; 64] by taking out its bits individually and shuffling them around. Then when you unshuffle and turn it back into the address, you could dereference it again. Maybe with strict provenance we could do this though? It would be very expensive

Basically a tracing garbage collector, but if you only enable it when you already know a leak is happening, could be ok. Or we add a way to bisect to leak via the basic block counter.