miri: don't report memory leaks for static data

Currently, miri reports a memory leak for a static with heap allocated data. This is somewhat expected, as statics don’t run destructors and indeed leak memory. However, this is not error, and ideally shouldn’t be reported by miri as such.

See https://github.com/matklad/once_cell/pull/45/commits/327f4e24678b5930d129e79b61023a33499961be for an example.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 22 (15 by maintainers)

Commits related to this issue

Most upvoted comments

To avoid continuing this discussion in a closed issue, I opened https://github.com/rust-lang/miri/issues/1318.

It would be really sad if miri simply could not support checking crossbeam-epoch, or anything that depends on it.

Yeah, I agree that would be sad. However, re-adding that code might be even more sad.^^

See ptr_int_arithmetic removed in this commit for the awful things we used to do.

Ah, yes raw pointers may be NULL, dangling and unaligned, that is fine, as long as they do not get dereferenced (* operator – even when no memory access happens).

They might also be using AtomicPtr which under the hood does a cast to usize – see https://github.com/rust-lang/rust/pull/70765.

Oh, heh. I never thought about heap pointers being leaked into statics. Also calls to Box::leak should probably not trigger the leak errors.

Maybe we should, before running the check, recursively mark anything reachable by a static as static itself.

And we should add a hook to Box::leak to make it mark its memory as static (we can use rustc_diagnostic_item to get the DefId of Box::leak