290681 2025-03-28 23:50:31 -0700 "call_indirect to a null table entry" after 230257 wasm table grows 2025-10-19 12:29:17 -0700 1 1 1 Unclassified WebKit WebAssembly Safari Technology Preview Mac (Apple Silicon) macOS 15 NEW InRadar P2 Normal --- 1 terrorjack webkit-unassigned terrorjack webkit-bug-importer ysuzuki oldest_to_newest 2107079 0 terrorjack 2025-03-28 23:50:31 -0700 Hi folks, I'm running a wasm dynamic linker written in JS (https://gitlab.haskell.org/ghc/ghc/-/blob/master/utils/jsffi/dyld.mjs) in browser, which allocates an anyfunc table with initial size 1, and invokes table.grow(1, func) 230257 times, and the table growth is interleaved with wasm execution. Now, it works fine in firefox/chrome, but in safari (both 18.3.1 and TP215) I'm seeing spurious "call_indirect to a null table entry" panics when the wasm code attempts to call_indirect into small indices of the table. The panic can be worked around by allocating a huge table upfront and never growing it, only filling the slots in the dynamic linker logic. I can provide more detailed instructions to reproduce if it helps, but it's not a single script and a bunch of wasm payloads, it requires installing a bunch of tools to proceed. So I'm just reporting the above information for now to see if it rings any bells. 2109133 1 webkit-bug-importer 2025-04-05 11:40:17 -0700 <rdar://problem/148665183> 2109330 2 ysuzuki 2025-04-06 21:51:35 -0700 Thanks! Can you attach the test case to reproduce the issue? 2110900 3 terrorjack 2025-04-14 10:25:02 -0700 Hi, I've created a relocatable binary distribution of the ghc wasm toolchain on aarch64-darwin at https://drive.google.com/file/d/13Gi_-1lMqD-HUJhb_4YVgYffPteWqPVY/view?usp=sharing. Here are the steps to use it to reproduce the issue: - Download and extract it to a temporary path - `export PATH=$PWD/.ghc-wasm/nodejs/bin:$PATH` - `export NODE_PATH=$PWD/.ghc-wasm/nodejs/lib/node_modules` - `./.ghc-wasm/wasm32-wasi-ghc/bin/wasm32-wasi-ghc --interactive -fghci-browser -fghci-browser-port=8000` You'll see a prompt like `Open http://127.0.0.1:8000/main.html or import http://127.0.0.1:8000/main.js to boot ghci`. You can now open Safari and open the inspector panel, open the page as instructed, the `wasm32-wasi-ghc` console will be unfrozen and accept user input. Now, the crash in this bug can be reproduced by typing the following two lines: - `foreign import javascript "new Promise(res => setTimeout(res, 1024, 114514))" test :: IO Int` - `test` You can also modify `./.ghc-wasm/wasm32-wasi-ghc/lib/dyld.mjs` script in place, that's the dynamic linker program we're using. Let me know if there's any difficulty in the reproducer, thanks a lot! 2152444 4 terrorjack 2025-10-19 12:29:17 -0700 So it turns out that the table.grow() JS API is broken, but the table.grow wasm instruction works, so this issue can be worked around by calling a wasm function that's in charge of growing the table. I've implemented the workaround in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14988, but it would still be nice for upstream to fix it some day.