Memory leaks do not show where the original allocation occurs

[nonl4331]

Take the following code:

Box::into_raw(Box::new(5));

which produces the following output with cargo miri run:

The following memory was leaked: alloc1672 (Rust heap, size: 4, align: 4) {
    05 00 00 00                                     │ ....
}

The error message does not mention where the allocation of the memory that has been leaked occurs. A mention of what line the allocates the leaked memory or a backtrace of calls leading up to the allocation would make it significantly easier to figure out what needs to be done to fix the memory leak especially in more complex situations.

[saethlin]

We could record a backtrace or a span for the allocation location in Miri, but these leak reports are produced by code in rustc_const_eval. I'm hesitant to thread a Miri customization path down through all the code, maybe a first step is to see what the overhead is of collecting a backtrace upon creating every allocation? It's probably cheap enough to always collect a backtrace for heap allocations...

[nonl4331]

Would a comment mentioning using miri-track-alloc-id be an option if collecting a backtrace on every allocation is too much? This would be particularly relevant to those who are new to using miri.

[nonl4331]

That was completely accidental, I did not intend to click the close with comment button.

[oli-obk]

I'm hesitant to thread a Miri customization path down through all the code

Don't we already have a callback for creating new allocs' stacked borrow datastructure? Maybe we can do sth there.

For diagnostics it seems alright to use thread local storage instead of threading (heh) through an InterpCx all the way

[saethlin]

Printing some advice would be better than nothing, but if the user is debugging a leak in a program that requires isolation to be off, it is possible that the offending allocation ID changes randomly between runs.

I am also currently debugging this: https://github.com/rust-lang/miri-test-libstd/actions/runs/4395316008/jobs/7697019211#step:4:770 which is a leak which only appears after 15 minutes of runtime, with isolation off.

We can certainly hold the state that's required in Miri's AllocExtra, my concern is then threading that information down to the leak reporting code. You're right that the Extra gets carried down with the leaked allocation... Maybe there's a way to retrieve it all the way down in the formatting code?

[RalfJung]

Thanks for the report! However, I think this is a duplicate of #1481.