3 ms·

Has anyone tried to Valgrind the rust runtime?

• pornel 2y ago
  It works okay with Rust, but it's not really needed, except when integrating C code with Rust. For verifying unsafe code, Rust has a MIRI interpreter that catches UB more precisely, e.g. it knows Rust's aliasing rules, precise object boundaries, and has access to lifetimes (they don't survive compilation). Non-deliberate leaking of memory in Rust is not possible for the majority of Rust types. In safe Rust it requires a specific combination of a refcounted type that uses interior mutability which contains a type that makes the refcounted smart pointer recursive. Types that meet all three conditions at once are niche. The only annoyance/incompatibility is that Valgrind complains that global variables are leaked. Rust does that intentionally, because static destructors have the same problem as SIOF[1] in reverse, plus tricky interactions with atexit mean there's no reliable way to destruct arbitrary globals. [1]: https://en.cppreference.com/w/cpp/language/siof https://en.cppreference.com/w/cpp/language/siof
  • vlovich123 2y ago
    Hard disagree that it’s not needed. MIRI’s ability to verify non-trivial examples of code is quite limited so I generally just discount it. Valgrind goes beyond just asan+msan with heap and CPU profiling which can be useful if you’re trying to extract every last bit of performance.
• rwmj 2y ago
  Yes we do, regularly, and unlike the other response, it's necessary as you can have leaks in C libraries even if they happen to be called from rust.