Bug 263913
| Summary: | WebAssembly memory corruption on arm64 macOS and iOS | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brooke Vibber <bvibber> |
| Component: | WebAssembly | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | justin_michaud, keith_miller, mark.lam, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 17 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | Unspecified | ||
Brooke Vibber
While testing my WebAssembly media codecs library, I found that the AV1 decoder is failing in at least some cases on ARM64 Macs and iPhones running Safari, while it works as expected on x86_64 Macs and in Firefox or Chrome on ARM64 Macs.
The symptom is a failure of call_indirect signature validation, which likely indicates corruption of a function pointer via some earlier error.
I haven't been able to narrow down where/how exactly in the dav1d codec library code it's corrupting data, but have a very stable test case with a .wasm file, two packets of input data, and the surrounding JavaScript wrapper from emscripten:
Live test case: https://brionv.com/misc/wasm-safari-bug/
Test case with all component parts ready to run in a git repo: https://github.com/brion/wasm-safari-bug
Compiling dav1d with -O2 or -Os avoids the bug, but since it runs correctly in other browsers and in WebKit on x86_64 I think it's not likely to be a clang/llvm issue.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/117804393>
Mark Lam
Hi Brion, which version of WebKit did you saw this issue on? Is it the Safari 17 that came with a macOS install (which one)? Or is it on a local WebKit build?
Brooke Vibber
(In reply to Mark Lam from comment #2)
> Hi Brion, which version of WebKit did you saw this issue on? Is it the
> Safari 17 that came with a macOS install (which one)? Or is it on a local
> WebKit build?
I have so far reproduced it in:
* macOS 14.1's stock Safari
* iOS 17.1's stock Safari
* a local WebKit build from main a few days ago
* WebKit nightly builds from a few days ago, 3 months ago, and 6 months ago
Brooke Vibber
Also the current Safari Technology Preview exhibits the bug on my M1 MacBook Air.
Justin Michaud
You are right, this is a JSC bug.
Thank you so much for reporting this, and for making such a tidy reproduction repo. I cannot explain how much easier that makes this.
I was able to reproduce on a very recent nightly build. This configuration also makes the issue go away:
__XPC_JSC_useBBQJIT=0 __XPC_JSC_useConcurrentJIT=0 run-safari -ExtensionsEnabled NO
This of course reproduces the issue:
__XPC_JSC_useBBQJIT=1 __XPC_JSC_useOMGJIT=0 __XPC_JSC_useConcurrentJIT=0 run-safari -ExtensionsEnabled NO
This looks like a BBQ bug, which is our new baseline compiler tier that was introduced in macOS 17.
Thanks again, I will try to bisect which function is the cause.
Brooke Vibber
(In reply to Justin Michaud from comment #5)
> You are right, this is a JSC bug.
>
> Thank you so much for reporting this, and for making such a tidy
> reproduction repo. I cannot explain how much easier that makes this.
...
> This looks like a BBQ bug, which is our new baseline compiler tier that was
> introduced in macOS 17.
>
> Thanks again, I will try to bisect which function is the cause.
oh good I'm glad the repro is workable! it's always tough chopping down these big code blobs ;) :D
Justin Michaud
Hey! Thank you so much for this repro case, it was very helpful in determining the root cause of a few different bugs. Sorry for the delay in responding publicly.
The fix was landed here: https://github.com/WebKit/WebKit/pull/22029
Cheers!
Brooke Vibber
Woohoo! Thanks for the fix. :D