Wasmtime GitHub notifications bot (Jul 03 2024 at 13:50): Wasmtime GitHub notifications bot (Jul 03 2024 at 13:50):pimeys added the bug label to Issue #8897.
Wasmtime GitHub notifications bot (Jul 03 2024 at 13:50):pimeys opened issue #8897:
Test Case
Load _any_ wasm component (wasip2) with wasmtime 21.0.1, if you compile the rust against musl, a warning is printed to the terminal:
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIEThe component and the whole system works correctly, but the log is confusing and there's no way to tell if something is actually broken.
Expected Results
It should work as with builds against glibc, or builds on macos with no libunwind warning printed to the terminal.
Actual Results
I can't seem to find anything being broken really...
Versions and Environment
Wasmtime version or commit: 21.0.1
Operating system: nixos linux unstable
Architecture: x86_64-unknown-linux-musl for the host and wasm32-wasip1 for the guest.
Extra Info
I found issues from the past, such as
https://github.com/wasmerio/wasmer/issues/2150
https://github.com/bytecodealliance/wasmtime/issues/1904But nothing more recent...
Wasmtime GitHub notifications bot (Jul 03 2024 at 14:00):pimeys edited issue #8897:
Test Case
Load _any_ wasm component (wasip2) with wasmtime 21.0.1, if you compile the rust host against musl, a warning is printed to the terminal:
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIEThe component and the whole system works correctly, but the log is confusing and there's no way to tell if something is actually broken.
Expected Results
It should work as with builds against glibc, or builds on macos with no libunwind warning printed to the terminal.
Actual Results
I can't seem to find anything being broken really...
Versions and Environment
Wasmtime version or commit: 21.0.1
Operating system: nixos linux unstable
Architecture: x86_64-unknown-linux-musl for the host and wasm32-wasip1 for the guest.
Extra Info
I found issues from the past, such as
https://github.com/wasmerio/wasmer/issues/2150
https://github.com/bytecodealliance/wasmtime/issues/1904But nothing more recent...
Wasmtime GitHub notifications bot (Jul 03 2024 at 16:57):fitzgen commented on issue #8897:
Seems like a regression of #1904 and #1914.
FWIW, we do not rely on the system's libunwind for correctness, we only emit
.eh_frameand call__register_framefor the benefit of tools like profilers. You can also turn this off via https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.native_unwind_infoIIRC, different libc implementations have different signatures for
__register_frame, and this might be what we are running into here. If so, that isn't really something we can fix...
Wasmtime GitHub notifications bot (Jul 03 2024 at 16:57):fitzgen commented on issue #8897:
IIRC, different libc implementations have different signatures for
__register_frame, and this might be what we are running into here. If so, that isn't really something we can fix...Context:
Wasmtime GitHub notifications bot (Jul 03 2024 at 19:21):pimeys commented on issue #8897:
Is there any way to hide this message or will it break any functionality?
Wasmtime GitHub notifications bot (Jul 03 2024 at 19:48):fitzgen commented on issue #8897:
I believe it is the libunwind implementation printing the message, not Wasmtime.
You can turn off Wasmtime's generation of unwind info via https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.native_unwind_info which should make it so that the message stops printing.
Wasmtime GitHub notifications bot (Jul 04 2024 at 08:30):pimeys commented on issue #8897:
Yeah, this solved it for us. I don't really know should I close this issue or not. It's kind of still an issue if wanting to use the native unwind info, but also wanting to target musl.
Wasmtime GitHub notifications bot (Jul 08 2024 at 13:46):alexcrichton commented on issue #8897:
This cropping up again is a consequence of https://github.com/bytecodealliance/wasmtime/pull/8028 and how
dlsymlooks like it always returns NULL in a static build. This means that if you build a static binary, which I believe you're doing here, then it'll always think it's using libgcc which is incorrect.So effectively this boils down to the mechanism used to detect libgcc-vs-libunwind. Another possible option is to use weak symbols but that's not possible in stable Rust so would require some C trickery to do that. I don't know of other options myself.
Wasmtime GitHub notifications bot (Jul 08 2024 at 13:51):bjorn3 commented on issue #8897:
You can use weak symbols from inline asm, right? Would require a separate implementation for each architecture though.
Wasmtime GitHub notifications bot (Jul 08 2024 at 14:34):alexcrichton commented on issue #8897:
Oh? I had no idea! If that works that might be a reasonable way to go here
Wasmtime GitHub notifications bot (Oct 16 2024 at 23:00):kate-goldenring commented on issue #8897:
We are encountering this in Spin with Wasmtime v25.0.0: https://github.com/fermyon/spin/issues/2889
Wasmtime GitHub notifications bot (Oct 22 2024 at 16:49):alexcrichton closed issue #8897:
Test Case
Load _any_ wasm component (wasip2) with wasmtime 21.0.1, if you compile the rust host against musl, a warning is printed to the terminal:
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIEThe component and the whole system works correctly, but the log is confusing and there's no way to tell if something is actually broken.
Expected Results
It should work as with builds against glibc, or builds on macos with no libunwind warning printed to the terminal.
Actual Results
I can't seem to find anything being broken really...
Versions and Environment
Wasmtime version or commit: 21.0.1
Operating system: nixos linux unstable
Architecture: x86_64-unknown-linux-musl for the host and wasm32-wasip1 for the guest.
Extra Info
I found issues from the past, such as
https://github.com/wasmerio/wasmer/issues/2150
https://github.com/bytecodealliance/wasmtime/issues/1904But nothing more recent...
Last updated: Dec 23 2024 at 12:05 UTC