Hoping White (Jul 23 2024 at 09:19): Hoping White (Jul 23 2024 at 09:19):I am using wasmtime in an embedded way. Wasmtime is in a DLL, but when I close the DLL, it always crashes the host process. On the other way, Wasmi is fine. So I wonder if wasmtime is multithreaded, it creates some threads when running?
If this is true, is there any way to close all the threads before I close the DLL?
Hoping White (Jul 23 2024 at 09:21):I already tried to only enable runtime and cranelift features, because parallel-compile uses rayon. But it does not work.
Alex Crichton (Jul 23 2024 at 14:53):Can you share details of the crash? Wasmtime's only background threads are the ones used during compilation.
Hoping White (Jul 24 2024 at 01:37):I am trying to write a unity game using Rust, in order to achieve hot
loading, and ultimately run with wasm. In order to be compatible with
Android and iOS, I chose wasmtime and wasmi, which have essentially the
same interface, so the code is almost the same. In general, when Unity's
editor crashes, there will be crash information in the editor.log, but in
this kind of crash, there is absolutely no crash log. Initially, in
wasmtime mode, as soon as the dll is closed, Unity crashes after a few
seconds, while wasmi mode has no problems at all. I always thought there
was something wrong with my code until I found out that if I don't use wasm
and directly use Rust runtime in multi-thread mode, it will crash. So, I
suspect that the crash may be caused by threads created in the dll
accessing certain global variables after the dll is closed. So I tried
turning off wasmtime's parallel compilation, only to find that it still
crashes. So I wanted to know if there are any other threads running.
询问GPT-4o获得更好的回答
Zulip notifications <noreply@zulip.com> 于2024年7月23日周二 22:55写道：
Soni L. (Jul 24 2024 at 03:12):rust-std is not unload-safe, we don't know enough about wasmtime to tell if wasmtime is unload-safe (it would have to be entirely no-std at the very least, there may be other issues as well)
Hoping White (Jul 24 2024 at 03:20):I tried dropping wasmtime and waiting for a few seconds before unloading,
and found that it didn't crash. But it still crashes in wasmtime threads
mode, so it looks like it's still a thread-related issue.
Zulip notifications <noreply@zulip.com> 于2024年7月24日周三 11:14写道：
Hoping White (Jul 24 2024 at 09:29):My test code is written incorrectly, did not actually close the dll, as before, as long as it is closed, it will crash.
bjorn3 (Jul 24 2024 at 13:57):Do you have a backtrace of the crash?
Alex Crichton (Jul 24 2024 at 14:30):Are you using wasmtime-wasi? That might enable Tokio usage which might enable background threads as well. Otherwise though Wasmtime does not spawn background threads except for its rayon and tokio usage.
Hoping White (Jul 25 2024 at 01:31):No, I don't have a backtrace. Actually, the Unity editor did not crash as the DLL closed immediately. I can get the debug log right after dll closing. But I don't see any crash log in the Unity Editor.log.
Hoping White (Jul 25 2024 at 01:33):Alex Crichton said:
Are you using
wasmtime-wasi? That might enable Tokio usage which might enable background threads as well. Otherwise though Wasmtime does not spawn background threads except for itsrayonandtokiousage.
The target wasm32-unknown-unknown will crash in wasmtime, but not in wasmi.
Alex Crichton (Jul 25 2024 at 14:10):Oh you know it's probably our call to AddVectoredExceptionHandler. That is never unregistered meaning that if you unload the dll and some later exception happens then it'll execute unmapped code which might be what's happening
Alex Crichton (Jul 25 2024 at 14:11):that might also explain the lack of crash report since it's dying while trying to generate a crash report
Alex Crichton (Jul 25 2024 at 14:13):I think it'd be reasonable to refactor that to call RemoveVectoredExceptionHandler when engines were all dropped. It won't entirely be trivial due to the way things are structured right now but I don't think it'd be too bad either.
Alex Crichton (Jul 25 2024 at 14:13):is that something you'd be interested in investigating?
Soni L. (Jul 25 2024 at 15:05):(why do you write unload-safe code in rust when the language explicitly doesn't support that use-case?)
Hoping White (Jul 26 2024 at 02:16):Alex Crichton said:
is that something you'd be interested in investigating?
You're right. I add a handle in Engine, and RemoveVectoredExceptionHandler before drop, and it does not crash now.
Alex Crichton (Jul 26 2024 at 16:30):Ok thanks for checking! I've submitted https://github.com/bytecodealliance/wasmtime/pull/9022 to be able to expose this at the engine level. Note though that it's a fundamentally unsafe method so we effectively can't guarantee it will continue to work in all situations. If you encounter issues though we can try fix them or at least document them.
Hoping White (Jul 29 2024 at 01:17):This is great, thank you very much.
Last updated: Nov 22 2024 at 16:03 UTC