ueno opened Issue #1904:
When wasmtime is compiled with
cargo build --target x86_64-unknown-linux-musl
, it produces a runtime warning as below:$ ./target/x86_64-unknown-linux-musl/debug/wasmtime tests/wasm/hello_wasi_snapshot1.wat libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE Hello, world!
What are the steps to reproduce the issue?
See above.What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?
I am actually not sure about the impact, but it looks like the FDE record is corrupted in the generated code.Which Wasmtime version / commit hash / branch are you using?
git master (f4e3e4efde28ac90be9fd68dcbda2943b3851155)If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)
- rustc 1.43.0 (4fb7144ed 2020-04-20)
- Fedora 32 (x86_64)
ueno labeled Issue #1904:
When wasmtime is compiled with
cargo build --target x86_64-unknown-linux-musl
, it produces a runtime warning as below:$ ./target/x86_64-unknown-linux-musl/debug/wasmtime tests/wasm/hello_wasi_snapshot1.wat libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE Hello, world!
What are the steps to reproduce the issue?
See above.What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?
I am actually not sure about the impact, but it looks like the FDE record is corrupted in the generated code.Which Wasmtime version / commit hash / branch are you using?
git master (f4e3e4efde28ac90be9fd68dcbda2943b3851155)If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)
- rustc 1.43.0 (4fb7144ed 2020-04-20)
- Fedora 32 (x86_64)
peterhuene assigned Issue #1904:
When wasmtime is compiled with
cargo build --target x86_64-unknown-linux-musl
, it produces a runtime warning as below:$ ./target/x86_64-unknown-linux-musl/debug/wasmtime tests/wasm/hello_wasi_snapshot1.wat libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE Hello, world!
What are the steps to reproduce the issue?
See above.What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?
I am actually not sure about the impact, but it looks like the FDE record is corrupted in the generated code.Which Wasmtime version / commit hash / branch are you using?
git master (f4e3e4efde28ac90be9fd68dcbda2943b3851155)If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)
- rustc 1.43.0 (4fb7144ed 2020-04-20)
- Fedora 32 (x86_64)
peterhuene commented on Issue #1904:
I'm able to reproduce this and I'll investigate.
peterhuene commented on Issue #1904:
There are two warnings because two frame tables are being registered (each with two FDEs), one for the the wasm functions and one for the trampolines.
Here's one of the decoded table being passed to
__unw_add_dynamic_fde
:[ 20, 0, 0, 0, // CIE length: 20 bytes 0, 0, 0, 0, // CIE ID: 0 1, // Version: 1 0, // Agumentation (none) 1, // Code alignment factor 120, // Data alignment factor (-8) 16, // Return register: RAX 12, // Start of initial instructions 7, 8, 144, 1, 0, 0, 0, 0, 0, 0, // End of initial instructions 36, 0, 0, 0, // FDE length: 36 bytes 28, 0, 0, 0, // CIE offset: 4 (FDE length) + 24 (CIE record + length) = 28 0, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007ffff7dd0000 28, 0, 0, 0, 0, 0, 0, 0, // Function length: 28 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 86, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 36, 0, 0, 0, // FDE length: 36 bytes 68, 0, 0, 0, // CIE offset: 4 (this FDE length) + 40 (first FDE record + length) + 24 (CIE record + length) = 68 28, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007FFFF7DD001C 11, 0, 0, 0, 0, 0, 0, 0, // Function length: 11 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 69, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 0, 0, 0, 0, // FDE with length 0 (end of records marker) ]
This table appears correct.
There appears to be a libunwind issue unrelated to wasmtime that hasn't been investigated.
I'll see if I can debug into libunwind and see what's tripping it up.
peterhuene edited a comment on Issue #1904:
There are two warnings because two frame tables are being registered (each with two FDEs), one for the the wasm functions and one for the trampolines.
Here's one of the decoded frame tables being passed to
__unw_add_dynamic_fde
:[ 20, 0, 0, 0, // CIE length: 20 bytes 0, 0, 0, 0, // CIE ID: 0 1, // Version: 1 0, // Agumentation (none) 1, // Code alignment factor 120, // Data alignment factor (-8) 16, // Return register: RAX 12, // Start of initial instructions 7, 8, 144, 1, 0, 0, 0, 0, 0, 0, // End of initial instructions 36, 0, 0, 0, // FDE length: 36 bytes 28, 0, 0, 0, // CIE offset: 4 (FDE length) + 24 (CIE record + length) = 28 0, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007ffff7dd0000 28, 0, 0, 0, 0, 0, 0, 0, // Function length: 28 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 86, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 36, 0, 0, 0, // FDE length: 36 bytes 68, 0, 0, 0, // CIE offset: 4 (this FDE length) + 40 (first FDE record + length) + 24 (CIE record + length) = 68 28, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007FFFF7DD001C 11, 0, 0, 0, 0, 0, 0, 0, // Function length: 11 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 69, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 0, 0, 0, 0, // FDE with length 0 (end of records marker) ]
This table appears correct.
There appears to be a libunwind issue unrelated to wasmtime that hasn't been investigated.
I'll see if I can debug into libunwind and see what's tripping it up.
peterhuene edited a comment on Issue #1904:
There are two warnings because two frame tables are being registered (each with two FDEs), one for the the wasm functions and one for the trampolines.
Here's one of the decoded frame tables being passed to
__unw_add_dynamic_fde
:[ 20, 0, 0, 0, // CIE length: 20 bytes 0, 0, 0, 0, // CIE ID: 0 1, // Version: 1 0, // Agumentation (none) 1, // Code alignment factor 120, // Data alignment factor (-8) 16, // Return register: RAX 12, // Start of initial instructions 7, 8, 144, 1, 0, 0, 0, 0, 0, 0, // End of initial instructions 36, 0, 0, 0, // FDE length: 36 bytes 28, 0, 0, 0, // CIE offset: 4 (FDE length) + 24 (CIE record + length) = 28 0, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007ffff7dd0000 28, 0, 0, 0, 0, 0, 0, 0, // Function length: 28 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 86, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 36, 0, 0, 0, // FDE length: 36 bytes 68, 0, 0, 0, // CIE offset: 4 (this FDE length) + 40 (first FDE record + length) + 24 (CIE record + length) = 68 28, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007FFFF7DD001C 11, 0, 0, 0, 0, 0, 0, 0, // Function length: 11 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 69, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 0, 0, 0, 0, // FDE with length 0 (end of records marker) ]
This table appears correct.
There appears to be a libunwind issue unrelated to wasmtime that hasn't been investigated.
I'll see if I can debug into libunwind and see what's tripping it up.
peterhuene edited a comment on Issue #1904:
There are two warnings because two frame tables are being registered (each with two FDEs), one for the the wasm functions and one for the trampolines.
Here's one of the decoded frame tables being passed to
__unw_add_dynamic_fde
:[ 20, 0, 0, 0, // CIE length: 20 bytes 0, 0, 0, 0, // CIE ID: 0 1, // Version: 1 0, // Agumentation (none) 1, // Code alignment factor 120, // Data alignment factor (-8) 16, // Return register: RAX 12, // Start of initial instructions 7, 8, 144, 1, 0, 0, 0, 0, 0, 0, // End of initial instructions 36, 0, 0, 0, // FDE length: 36 bytes 28, 0, 0, 0, // CIE offset: 4 (FDE length) + 24 (CIE record + length) = 28 0, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007ffff7dd0000 28, 0, 0, 0, 0, 0, 0, 0, // Function length: 28 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 86, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 36, 0, 0, 0, // FDE length: 36 bytes 68, 0, 0, 0, // CIE offset: 4 (this FDE length) + 40 (first FDE record + length) + 24 (CIE record + length) = 68 28, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007FFFF7DD001C 11, 0, 0, 0, 0, 0, 0, 0, // Function length: 11 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 69, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 0, 0, 0, 0, // FDE with length 0 (end of records marker) ]
This table appears correct.
There appears to be a libunwind issue unrelated to wasmtime that hasn't been investigated, although I'm not sure if that one is musl-related or not.
I'll see if I can debug into libunwind and see what's tripping it up.
peterhuene commented on Issue #1904:
This bug is due to Wasmtime expecting
__register_frame
(aliased to__unw_add_dynamic_fde
in libunwind) to take a whole table like it does with libgcc, but musl, like the macOS implementation, expects a single FDE.We need to update the
UnwindRegistry
to iterate the FDEs like we do for macOS.
peterhuene edited a comment on Issue #1904:
There are two warnings because two frame tables are being registered, one for the the wasm functions and one for the trampolines.
Here's one of the decoded frame tables being passed to
__unw_add_dynamic_fde
:[ 20, 0, 0, 0, // CIE length: 20 bytes 0, 0, 0, 0, // CIE ID: 0 1, // Version: 1 0, // Agumentation (none) 1, // Code alignment factor 120, // Data alignment factor (-8) 16, // Return register: RAX 12, // Start of initial instructions 7, 8, 144, 1, 0, 0, 0, 0, 0, 0, // End of initial instructions 36, 0, 0, 0, // FDE length: 36 bytes 28, 0, 0, 0, // CIE offset: 4 (FDE length) + 24 (CIE record + length) = 28 0, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007ffff7dd0000 28, 0, 0, 0, 0, 0, 0, 0, // Function length: 28 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 86, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 36, 0, 0, 0, // FDE length: 36 bytes 68, 0, 0, 0, // CIE offset: 4 (this FDE length) + 40 (first FDE record + length) + 24 (CIE record + length) = 68 28, 0, 221, 247, 255, 127, 0, 0, // Function address: 0x00007FFFF7DD001C 11, 0, 0, 0, 0, 0, 0, 0, // Function length: 11 bytes 66, // Start of call frame instructions 14, 16, 134, 2, 67, 13, 6, 69, 12, 7, 8, 0, 0, 0, 0, // End of call frame instructions 0, 0, 0, 0, // FDE with length 0 (end of records marker) ]
This table appears correct.
There appears to be a libunwind issue unrelated to wasmtime that hasn't been investigated, although I'm not sure if that one is musl-related or not.
I'll see if I can debug into libunwind and see what's tripping it up.
peterhuene closed Issue #1904 (assigned to peterhuene):
When wasmtime is compiled with
cargo build --target x86_64-unknown-linux-musl
, it produces a runtime warning as below:$ ./target/x86_64-unknown-linux-musl/debug/wasmtime tests/wasm/hello_wasi_snapshot1.wat libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE Hello, world!
What are the steps to reproduce the issue?
See above.What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?
I am actually not sure about the impact, but it looks like the FDE record is corrupted in the generated code.Which Wasmtime version / commit hash / branch are you using?
git master (f4e3e4efde28ac90be9fd68dcbda2943b3851155)If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)
- rustc 1.43.0 (4fb7144ed 2020-04-20)
- Fedora 32 (x86_64)
peterhuene commented on Issue #1904:
So #1914 fixes these warnings and Wasmtime now correctly registers the JIT unwind information for musl builds of Wasmtime.
Unfortunately, we discovered that musl-targeted LLVM's libunwind is unable to walk stacks properly from signal handlers (see discussion in #1914), which is what Wasmtime needs to capture trap backtraces. As a result, musl-targeted Wasmtime won't show any backtraces for traps.
We have a related issue to this where foreign frames that don't have unwind information (#1845) also trip this up. We may stop using the system-provided unwinder for walking the stack in the future and this will likely fix this issue for musl builds as well.
Last updated: Dec 23 2024 at 12:05 UTC