Stream: git-wasmtime

Topic: wasmtime / issue #4099 wasmtime_wasi: env leaking memory

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 15:00):

YannikSc edited issue #4099:

Note: I'm not sure if my implementation is correct, so please correct me if my implementation or expectations are wrong.

Test Case

Example project is available here

Steps to Reproduce

Expected Results

It might be a user issue, as I'm not sure if my implementation is correct, but I would assume, that it is.

So in this case my expectation would be, that the memory at the end is likely the same as the one at the start.

Actual Results

The memory size at the end is (for 2000 function calls in my example) ~10 time bigger than at the beginning

Versions and Environment

Wasmtime & Wasmtime_wasi version: 0.36.0

uname -srm: Linux 5.17.5-zen1-1-zen x86_64

edit: This also happens if the env method is used

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 15:05):

alexcrichton commented on issue #4099:

cc @sunfishcode this seems to be an unfortunate interaction between the current command support in LLVM/LLD and wasi-libc perhaps? I don't think that the problem is with inherit_env, rather simply any env var being defined. (this reproduces when defining just a single env var). Also note that this isn't a leak in Wasmtime, but rather then wasm module itself.

The do_something export is wrapped automatically by LLD so that every time it's called it first calls __wasm_call_ctors followed by a call to __wasm_call_dtors. For this particular wasm module the ctors initializes the environment but the dtors don't actually free anything, so the environment is initialized every time the function is called, which results in the apparent leak.

@sunfishcode is this perhaps updated in wasi-libc already? Does the Rust toolchain just need to update its wasi-libc version?

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 15:40):

YannikSc commented on issue #4099:

After some more checking, I can confirm that it happens also for only a single .env() call.

I also noticed a leak when using the .preopened_dir() function. I'm not sure if it's the same cause, but I thought it would be worth to mention.

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 15:42):

alexcrichton commented on issue #4099:

That's likely the same issue where __wasm_call_ctors is repeatedly initializing internal state without either reusing prior state or cleaning up the prior state.

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2022 at 01:31):

sunfishcode commented on issue #4099:

The way the LLVM backend and wasm-ld work now is to assume that a "command", which is the default mode, is called into only once. To build a module that can be called into multiple times, the toolchain now expects users to build in "reactor". The rust toolchain unfortunately does not yet have a flag for enabling "reactor" mode. We should consider adding one. Though adding one that can be relatively stable will require answering complex questions about "what is a wasm cdylib?" and "what is a wasm reactor?" which have been difficult to answer while module-linking has been in flux.

It is a change from previous versions. It used to be the case that "command" executables were more forgiving about being called multiple times. Some things didn't work, and it wasn't ever documented or anticipated that calling into wasm modules multiple times would work, but it does appear to have turned out to work in practice for some users. When I made the change, quite a while ago at this point, I was trying to fix the things that didn't work, and I didn't realize how many people were depending on the old behavior continuing to work the way it did. These changes are now showing up in toolchains and unfortunately breaking these users' code.

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2022 at 15:12):

alexcrichton commented on issue #4099:

I'm going to close this because I don't believe that this is a bug in Wasmtime itself, but @YannikSc if you'd like this would perhaps be a good candidate for opening as an issue on the wasi-libc repository.

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2022 at 15:12):

alexcrichton closed issue #4099:

Note: I'm not sure if my implementation is correct, so please correct me if my implementation or expectations are wrong.

Test Case

Example project is available here

Steps to Reproduce

Expected Results

It might be a user issue, as I'm not sure if my implementation is correct, but I would assume, that it is.

So in this case my expectation would be, that the memory at the end is likely the same as the one at the start.

Actual Results

The memory size at the end is (for 2000 function calls in my example) ~10 time bigger than at the beginning

Versions and Environment

Wasmtime & Wasmtime_wasi version: 0.36.0

uname -srm: Linux 5.17.5-zen1-1-zen x86_64

edit: This also happens if the env method is used

Last updated: Oct 23 2024 at 20:03 UTC