In wasmerio/wasmer#3920, we ran into an issue on Windows (failing build) which results in bash erroring out with RuntimeError: indirect call type mismatch.

Steps To Reproduce

$ wasmer run-unstable sharrattj/[email protected] --entrypoint=bash -- -c "ls -l /usr/coreutils/*.md && ls -l /lib/python3.6/*.py"
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Capabilities insufficient
2023-05-30T14:28:02.202145Z  WARN ThreadId(18) wasmer_wasix::syscalls::wasix::proc_exec: failed to create subprocess for fork - notcapable (error 76)
error: RuntimeError: indirect call type mismatch
    at <unnamed> (<module>[583]:0x96372)
    at <unnamed> (<module>[814]:0xc044c)
    at <unnamed> (<module>[51]:0x846b)
╰─▶ 1: RuntimeError: indirect call type mismatch
           at <unnamed> (<module>[583]:0x96372)
           at <unnamed> (<module>[814]:0xc044c)
           at <unnamed> (<module>[51]:0x846b)

Context

From what I've been able to find, resolving something relative to the the root directory (/) would hits an error branch because we call WasiFs::get_inode_at_path_inner() and in that part of the code component is Component::RootDir and we end up doing a lookup in entries with "\" as the key (in my test, it only contained "." and "/").

https://github.com/wasmerio/wasmer/blob/9c81cb8cd376c9a2dd23fa8d9b032a3a1eeaf12f/lib/wasi/src/fs/mod.rs#L1140-L1141

I believe this Errno::Notcapable causes forking to fail, which means the caller (bash) goes down a different code path and triggers a RuntimeError: indirect call type mismatch.

https://github.com/wasmerio/wasmer/blob/9c81cb8cd376c9a2dd23fa8d9b032a3a1eeaf12f/lib/wasi/src/syscalls/wasix/proc_exec.rs#L68-L73

I'm not sure why we get a mismatched signature error. It may be that there was a long-standing bug, and we've never seen it before because forking has never failed. @john-sharratt may be a better person to talk to about it than me, though.