how to catch memory corruption only in wasm target

[tidal coyote]

anybody have good ideas for catching probable memory corruption that only occurs in my webassembly target?
I have some extra glue code which could be the culprit, and the changed memory (according to the chrome debugger anyway) changes when stepping into a C++ class's
default constructor (but not yet initializing the members, this occurs in a dependency of mine).

Also the problem "goes away" (but another one appears later) if you increase the initial memory in build.zig, but I placed breakpoints on all wasm memory.grow instructions and don't see that being reached during the change.

also I tried to use valgrind to see if anything funky is going on in the native target but I just get unsupported instructions

[tidal coyote]

just realized there's guidance for using valgrind with zig and I'm going to do that

[tidal coyote]

ok I seem to have an invalid read inside the debug allocator

[tidal coyote]

I don't even use the debug allocator in wasm and valgrind shows no other issues bad writes before that, I wonder if something is corrupting within bounds.
I'd set a watchpoint on that allocator bucket and then reverse continue but rr doesn't work on this machine...

[tidal coyote]

could it be because I'm using the wasm allocator but have dependencies using C++ new/malloc?

I see that a call to new is kind of wiping out that memory region... although tbh that memory region was also allocated by the libc allocator

ok I think I found the memory corruption