Is there a strong reason why we wouldn't enable this by default at least for the CLI build? Having this available would be very useful for projects that use Wasmtime to run test suites, such as StarlingMonkey.
I couldn't find any comments on why it's not enabled by default, and it doesn't seem like it's pulling in some substantial amount of additional code
I was under the impression it wasn't complete enough to be available by default. Have you used it though and it's caught things? (I've always assume it's got false positives/negaitves to reduce the utility)
I have not yet used it, because it wasn't readily available :grimacing: I'll do a run of the StarlingMonkey test suite with it in a bit though, and report back
@Chris Fallin you worked on this, right? Do you have any recollection of what the reasoning was?
I believe it is just very much a beta feature: incomplete and somewhat buggy
no one has worked on it since the original intern who developed it
(meetings, will have a response in a few hours)
ok, brief thoughts: yes, I mentored the intern who built it. The current status is that it doesn't quite capture every C stdlib call one would want to capture to track allocations properly. The thought when we upstreamed it was that we wanted it in tree so it would get further contributions and refinements, and indeed we have seen at least one PR to enhance it, IIRC; but I wouldn't be comfortable having it be an advertised option until we know it works well
I'd be curious what you find with StarlingMonkey tests, @Till Schneidereit -- either it will (to my surprise) Just Work, or we'll find some holes that may not be too bad to patch :-)
Thank you for the context, @Chris Fallin, much appreciated!
Turns out it does indeed not Just Work for StarlingMonkey. Instead, it complains about the very first load, here. In the test case where this error occurs, REQUEST_HANDLER is at this point definitely initialized, via set_handler, invoked here. Given that none of this involves any allocations, this seems like a false positive?
Maybe, it's hard to say -- this sort of issue I'd need to dig deeply into with rr probably and unfortunately don't have the cycles right now
I don't think wmemcheck has the concept of static .data sections, it assumes everything is heap-allocated or stack allocated, so Till because your variable is in .data that's why it's a false positive
Oh, yes, this is a tricky case -- it doesn't have any information about memory layout (unlike, say, Valgrind which can look at the ELF headers of the program it's running) so it doesn't know where static data ends and heap begins. IIRC we discussed a heuristic "assume the initial memory size is all global data" but that leads to poor behavior when static data is much less than 64k. We similarly bake in an assumption about where LLVM places the shadow stack
In an ideal world, there would be a well-specified custom section that gives this information, produced by wasm-ld, that wmemcheck could consume
Last updated: Dec 06 2025 at 06:05 UTC