Put this Rust program in `a.rs`: use std::io::{stdin, Read}; fn main() { let mut buf = vec![]; if let Err(e) = stdin().read(&mut buf) { println!("{}", e) } } Then build it with: rustc a.rs Then run: valgrind --leak-check=full --show-leak-kinds=all --gen-suppressions=all ./a Then hit enter, to provide the running program with necessary input. On termination, Memcheck prints two suppressions. Here's the first one, which is enough to show the problem: { <insert_a_suppression_name_here> Memcheck:Leak match-leak-kinds: reachable fun:malloc fun:alloc fun:alloc_impl fun:allocate fun:exchange_malloc fun:new<std::sys::unix::mutex::Mutex> fun:from<std::sys::unix::mutex::Mutex> fun:_ZN3std10sys_common5mutex12MovableMutex3new17h4e64539bf4ba99a6E fun:new<std::io::buffered::bufreader::BufReader<std::io::stdio::StdinRaw>> fun:{closure#0} fun:{closure#0}<std::sync::mutex::Mutex<std::io::buffered::bufreader::BufReader<std::io::stdio::StdinRaw>>, std::io::stdio::stdin::{closure#0}> fun:{closure#0}<std::sync::mutex::Mutex<std::io::buffered::bufreader::BufReader<std::io::stdio::StdinRaw>>, std::lazy::{impl#10}::get_or_init::{closure#0}, !> fun:_ZN3std4sync4once4Once15call_once_force28_$u7b$$u7b$closure$u7d$$u7d$17ha9375aeb05e4aae3E fun:_ZN3std4sync4once4Once10call_inner17hb3a655ef2ff7c156E fun:call_once_force<std::lazy::{impl#10}::initialize::{closure#0}> fun:_ZN3std4lazy21SyncOnceCell$LT$T$GT$10initialize17h3a3ef5fbb9e2970eE fun:get_or_try_init<std::sync::mutex::Mutex<std::io::buffered::bufreader::BufReader<std::io::stdio::StdinRaw>>, std::lazy::{impl#10}::get_or_init::{closure#0}, !> fun:get_or_init<std::sync::mutex::Mutex<std::io::buffered::bufreader::BufReader<std::io::stdio::StdinRaw>>, std::io::stdio::stdin::{closure#0}> fun:_ZN3std2io5stdio5stdin17h94821c2f5cbdd619E fun:_ZN1a4main17h8bbda9164eb1d7fdE fun:_ZN4core3ops8function6FnOnce9call_once17hb0b8acf7ed5a9c1fE fun:_ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hedc3d4705fc28138E fun:_ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h478bd93d3dae3c53E fun:call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> fun:do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> fun:try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> fun:catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> fun:{closure#2} fun:do_call<std::rt::lang_start_internal::{closure#2}, isize> fun:try<isize, std::rt::lang_start_internal::{closure#2}> fun:catch_unwind<std::rt::lang_start_internal::{closure#2}, isize> fun:_ZN3std2rt19lang_start_internal17hd15a47be08101c28E fun:_ZN3std2rt10lang_start17h99d3162981a37fa3E } Suppressions are supposed to use *mangled* function names, but this has a mix of mangled and demangled names. I did some digging and discovered that physical stack frames are correctly showing as mangled, but inline stack frames are incorrectly showing as demangled. The Rust compiler tends to inline aggressively. This bug makes it very hard to write suppressions, because frames that might be inlined one day might be non-inlined later on after making moderate changes to a program. This bug is preventing me from adding a useful suppression for the Rust standard library. See https://github.com/rust-lang/rust/issues/80406 for details.
Does this depend on the rustc version used? For me, using rustc 1.59.0 (Fedora 1.59.0-4.fc35) this gives the following suggested suppression containing only mangled names: { <insert_a_suppression_name_here> Memcheck:Leak match-leak-kinds: reachable fun:malloc fun:_ZN3std10sys_common5mutex12MovableMutex3new17h2646f2e28ea823e5E fun:_ZN3std4sync4once4Once15call_once_force28_$u7b$$u7b$closure$u7d$$u7d$17h98678df0cf16ea4dE fun:_ZN3std4sync4once4Once10call_inner17he3d18740537fa3bdE fun:_ZN3std4lazy21SyncOnceCell$LT$T$GT$10initialize17h891c2c6ffca3e2c0E fun:_ZN3std2io5stdio5stdin17h949e7321c8afbf0eE fun:_ZN1a4main17h876e69675f7eef91E fun:_ZN4core3ops8function6FnOnce9call_once17h48286bf6bc4f60efE fun:_ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hb0df4d8d6062aec9E fun:_ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h32ab4c6ebefa7100E fun:_ZN3std2rt19lang_start_internal17h508e52d6dc339062E fun:_ZN3std2rt10lang_start17h64105b43701b787dE }
Even though I cannot easily replicate it I can see how this happens. For inlined functions we only store the (demangled) name we get from the DW_AT_name attribute. See the DiInlLoc in coregrind/m_debuginfo/storage.h: const HChar* inlinedfn; /* inlined function name */ This is filled in by ML_(addInlInfo) in coregrind/m_debuginfo/storage.c. Which is called by parse_inl_DIE using the results from get_inlFnName in coregrind/m_debuginfo/readdwarf3.c. get_inlFnName essentially looks up the DW_AT_name attribute, which is the demangled, human/source name. What we want is the DW_AT_linkage_name (or old style DW_AT_MIPS_linkage_name). What you could try is something like: diff --git a/coregrind/m_debuginfo/readdwarf3.c b/coregrind/m_debuginfo/readdwarf3.c index 5489f8d13..c800a921c 100644 --- a/coregrind/m_debuginfo/readdwarf3.c +++ b/coregrind/m_debuginfo/readdwarf3.c @@ -3129,7 +3129,7 @@ static const HChar* get_inlFnName (Int absori, CUConst* cc, Bool td3) nf_i++; if (attr == 0 && form == 0) break; get_Form_contents( &cts, cc, &c, False/*td3*/, nf ); - if (attr == DW_AT_name) { + if (attr == DW_AT_linkage_name || attr == DW_AT_MIPS_linkage_name) { HChar *fnname; if (cts.szB >= 0) cc->barf("get_inlFnName: expecting indirect string"); But I suspect that is not always available where DW_AT_name is. So we will have less information sometimes. Also everywhere inlinedfn is now used that expects it to already be demangled would need to explicitly demangle the name. So maybe we need to keep both?
Note that even when not using inline information; I think that suppression entries will similarly not match when the compiler does different inlining decisions. If we tell valgrind to not use the inline information (--read-inline-info=no), then generated suppression entries will only contain the non inlined calls. But if the compiler decides to inline more (or less), then there will be less (or more) entries in the suppression. So, as suggested by Mark, assuming we can always use the mangled name and then always use the inline info, we can then expect to have "more stable" number of stack frames put in the suppression entries (and so not depend anymore on the inline decisions). If mangled names are not found in the debug info, then it looks like we will/might need to make suppression info matching even more sophisticated (another name for complex :)).
> Does this depend on the rustc version used? I tried a few versions: 1.57.0, 1.60.0, nightly 1.62, they all behaved the same on my Ubuntu 21.10 box. It looks to me like you're not getting any inline frames in your stack trace. This could happen if you're using a Valgrind prior to the fix for bug 445668, maybe? Anyway, your diagnosis of the underlying problem sounds entirely correct to me.