iOS 18.0 Safari error at runtime with -fwasm-exceptions build

[tangobravo]

We have a codebase that gives a RuntimeError on iOS 18 Safari when compiled with -fwasm-exceptions. The same code with -fexceptions works fine. The -fwasm-exceptions build also works correctly on other browsers, platforms, and iOS versions.

I was able to reproduce this with the iOS 18.0 simulator running on an Apple Silicon Mac.

Here are some test links that demonstrate the behaviour difference between the exception modes when run on iOS 18.0:
JS: https://tango-bravo.net/zcvjs_exception_tests/js_SIMD_False/js_SIMD_False.html
WASM: https://tango-bravo.net/zcvjs_exception_tests/native_SIMD_False/native_SIMD_False.html

The top one runs to completion whereas the bottom one throws this RuntimeError midway through:

RuntimeError: call_indirect to a null table entry

NB: Both versions will have a console error when they try to upload performance results, this code was intended to be used from a local server that would handle the upload.

Simple cases (such as the example from https://emscripten.org/docs/porting/exceptions.html) works fine in both modes:
JS: https://tango-bravo.net/zcvjs_exception_tests/simple_throw_catch/js-exceptions.html
WASM: https://tango-bravo.net/zcvjs_exception_tests/simple_throw_catch/wasm-exceptions.html

I've also checked iOS simulators for 17.4, 17.5, 18.1 and 18.2 and this appears to be limited to 18.0.

I haven't been able to track down a build of Safari 18.0 for Mac so I haven't tested there. Seems AWS have an AMI image of macOS 15.0 which would probably ship with Safari 18.0 but I don't want to pay the minimum 24 hour reservation just for testing this.

The links I have shared for the builds were made last year but we can probably track down the commit and try building with different flags / emscripten versions etc if there's interest in trying to dig more into it.

The exceptions causing the issue stem from the gtsam project - https://github.com/borglab/gtsam - it's in template code and uses exceptions to step back during a Levenberg-Marquadt numerical optimisation, and there's possibly quite a lot of stuff on the stack that will need cleaning up as part of handling the exception. It's not a particularly minimal reproducer I'm afraid - we spent some time trying to get a more minimal test case but then discovered JS exceptions with the allowlist offered similar performance and didn't suffer from the issue, so we moved over to that instead.

We have previously seen Safari applying stricter limits on stack depth than other runtimes but at least from the exception stack that doesn't seem to be the case here.

[tangobravo]

Thanks to archive.org I've been able to download older macOS Safari Technology Preview builds. The one from June 2024 (version 197) was the first to support the latest macOS and does also reproduce the same RuntimeError with the wasm exception build.

From some spot checks I've found STP 207 was affected, and STP 208 was not.

Release notes here, but nothing stands out to me. It does reference the webkit commit range included.

Looking at the full set of commits in the range and searching through for WASM, these two directly mention exceptions:
WebKit/WebKit@bca4ade
WebKit/WebKit@308187e

And this one has talks about a wasm instance not being restored properly if tail calls are involved, which feels like another potential candidate:
WebKit/WebKit@f35184a

Not sure which of these commits were part of the final 18.0 Safari build and I don't currently have the time or inclination to bisect with JSC builds to verify the actual culprit, but hopefully that gives anyone interested a head start.

[sbc100]

So it sounds like this was maybe a bug in only 18.0 that was then fixed by 18.1?

Do we have any idea who many folks out there might be using exactly 18.0?