Thibault Charbonnier (Jul 26 2021 at 20:26): Thibault Charbonnier (Jul 26 2021 at 20:26):Another strange behavior; the docs says that wasm_engine_new_with_config takes ownership of the config, yet ASAN reports the following leak after wasm_engine_delete:
=================================================================
==19300==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x562625452c09 in malloc (/home/chasum/code/ngx_wasm_module/work/buildroot/nginx+0x161c09)
#1 0x7fc0aefcfc3e in alloc::alloc::alloc::h8eea693b11397046 /home/chasum/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:86:14
#2 0x7fc0aefcfc3e in alloc::alloc::Global::alloc_impl::hdd19e4608fbda4e9 /home/chasum/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:166:73
#3 0x7fc0aefcfc3e in _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$::allocate::hf61e18fb7f49870e /home/chasum/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:226:9
#4 0x7fc0aefcfc3e in alloc::alloc::exchange_malloc::h1859a431711d6c17 /home/chasum/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:316:11
#5 0x7fc0aefcfc3e in alloc::boxed::Box$LT$T$GT$::new::h01edfadf503f5f89 /home/chasum/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:185:9
#6 0x7fc0aefcfc3e in wasmtime::error::handle_result::h8723cdd7ac184b74 /home/chasum/code/wasmtime/crates/c-api/src/error.rs:26:28
#7 0x7fc0aefcfc3e in wasmtime_config_strategy_set /home/chasum/code/wasmtime/crates/c-api/src/config.rs:109:5
#8 0x5626257c5363 in ngx_wavm_engine_init /home/chasum/code/ngx_wasm_module/src/wasm/vm/ngx_wavm.c:102:12
...
All this config specifies is a compiler (lightbeam)
Thibault Charbonnier (Jul 26 2021 at 20:28):On this leak issue, Valgrind complains about a number of leaks/uninitialized bytes within wasmtime & wasm parsers, I'll post them here as well
bjorn3 (Jul 26 2021 at 20:38):It does indeed take ownership of the config itself. See the Box<wasm_config_t> as argument at https://github.com/bytecodealliance/wasmtime/blob/a2cfddff9c207704a76eee9cb8ba681d0cb96ebd/crates/c-api/src/engine.rs#L30
bjorn3 (Jul 26 2021 at 20:39):Do you free the error returned by wasm_config_strategy_set?
bjorn3 (Jul 26 2021 at 20:40):@Thibault Charbonnier
Alex Crichton (Jul 26 2021 at 21:05):It's not expected that anything should leak in the C API, so you may be forgetting to call a destructor (or similar), but there's always the possibility of a bug! If you can post the other leaks you're seeing I can try to help out a bit in debugging
Thibault Charbonnier (Jul 26 2021 at 21:10):I don't think it is returning any error
Alex Crichton (Jul 26 2021 at 21:11):To confirm, you're checking the return value of wasmtime_config_strategy_set and it's returning NULL? (if it returns non-null then the error needs to be deallocated)n
Thibault Charbonnier (Jul 26 2021 at 21:16):Indeed it is returning an error! Strange, I am only calling it as such:
err = wasmtime_config_strategy_set(wasm_config, WASMTIME_STRATEGY_LIGHTBEAM);
However, wasm_trap_message on this error triggers a segfault
Alex Crichton (Jul 26 2021 at 21:16):Ah I believe that's because lightbeam is disabled at compile-time by default. The wasm_trap_message function operates on a wasm_trap_t whereas the error is a wasmtime_error_t which uses wasmtime_error_message to extract the message
Alex Crichton (Jul 26 2021 at 21:17):(fwiw you probably don't want lightbeam because AFAIK it doesn't work even for simple modules at this time)
Thibault Charbonnier (Jul 26 2021 at 21:17):I do in this case, this is for Valgrind testing
Thibault Charbonnier (Jul 26 2021 at 21:17):Other compilers are much too slow
Alex Crichton (Jul 26 2021 at 21:18):oh sure, I just mean that I don't think lightbeam will actually successfully even compile anything
Alex Crichton (Jul 26 2021 at 21:18):and then nothing can run if nothing compiles
Thibault Charbonnier (Jul 26 2021 at 21:18):Oh?
Alex Crichton (Jul 26 2021 at 21:18):you can try to recompile wasmtime with lightbeam support but you'll probably run into either Rust panics or compile-time errors for wasm modules
Thibault Charbonnier (Jul 26 2021 at 21:19):So yes, this is a local build of wasmtime (not like the macos assertion)
Alex Crichton (Jul 26 2021 at 21:19):you should be able to build in lightbeam support with --features lightbeam, but we don't test lightbeam on CI (only that it builds, not that it runs), so it's unlikely to help you get much further
Thibault Charbonnier (Jul 26 2021 at 21:20):So that makes wasmtime practically untestable with Valgrind then
Thibault Charbonnier (Jul 26 2021 at 21:20):Ok, good to know! Thanks
Till Schneidereit (Jul 26 2021 at 21:23):one thing you could potentially do is compiling a module using wasmtime compile without Valgrind, and then running it under Valgrind. That takes the Cranelift codegen out of coverage, but obviously that'd be the case when using Lightbeam as well
Thibault Charbonnier (Jul 26 2021 at 21:24):Yes; thanks for the suggestion!
Thibault Charbonnier (Jul 29 2021 at 18:53):Thank you all again for the tips & info on lightbeam! I only see Valgrind complaining about a single uninitialized bytes in the wasm parser's end method, but it isn't reported by Valgrind 3.16 and above; maybe a false positive.
Last updated: Nov 22 2024 at 17:03 UTC