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?
I already tried to only enable runtime and cranelift features, because parallel-compile uses rayon. But it does not work.
Can you share details of the crash? Wasmtime's only background threads are the ones used during compilation.
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写道:
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)
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写道:
My test code is written incorrectly, did not actually close the dll, as before, as long as it is closed, it will crash.
Do you have a backtrace of the crash?
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.
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.
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 itsrayon
andtokio
usage.
The target wasm32-unknown-unknown will crash in wasmtime, but not in wasmi.
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
that might also explain the lack of crash report since it's dying while trying to generate a crash report
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.
is that something you'd be interested in investigating?
(why do you write unload-safe code in rust when the language explicitly doesn't support that use-case?)
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.
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.
This is great, thank you very much.
Last updated: Dec 23 2024 at 13:07 UTC