Bug 276953 - LLInt -> BBQ tiering up breaks wasm-vips
Summary: LLInt -> BBQ tiering up breaks wasm-vips
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebAssembly (show other bugs)
Version: WebKit Local Build
Hardware: Other Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2024-07-23 05:40 PDT by Kleis Auke Wolthuizen
Modified: 2024-08-27 09:00 PDT (History)
2 users (show)

See Also:


Attachments
Test on iMac Pro x64 (1.24 MB, image/png)
2024-08-26 14:38 PDT, Yusuke Suzuki
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kleis Auke Wolthuizen 2024-07-23 05:40:29 PDT
To reproduce, visit: https://wasm-vips.kleisauke.nl/playground/ and notice this in the JavaScript console:
"""
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Resource temporarily unavailable.  Aborting.
"""

Disabling the LLInt -> BBQ tiering up code using:
"""
export JSC_webAssemblyLLIntTiersUpToBBQ=0
"""

seems to resolve this issue on GNOME Web 47.alpha, which uses WebKitGTK 2.45.5.

Tested on Fedora Rawhide. Additionally, to ensure the SharedArrayBuffer (SAB) features can be used, you'll need to set:
"""
export JSC_useSharedArrayBuffer=1
"""

Context: https://github.com/kleisauke/wasm-vips/issues/69.
Comment 1 Radar WebKit Bug Importer 2024-07-30 05:45:02 PDT
<rdar://problem/132802316>
Comment 2 Kleis Auke Wolthuizen 2024-08-03 06:26:42 PDT
Still reproducible on WebKitGTK 2.45.6. PR https://github.com/WebKit/WebKit/pull/31320 renamed the WebAssembly JSC options to Wasm, so you have to use this env variable to disable the LLInt -> BBQ tiering up code now:
"""
export JSC_wasmLLIntTiersUpToBBQ=0
"""

I was also able to reproduce this on an Apple Mac mini 2018 with both Safari versions 17.4 and 17.2.1. Interestingly, it's not reproducible on Safari versions 17.3, 17.4.1 and 17.6 on an Apple Mac mini M2 (2023) or Apple Mac mini M1 (2020), which might suggests that the issue is reproducible only on x86-64 architectures.
Comment 3 Yusuke Suzuki 2024-08-26 14:34:19 PDT
Looks like Trunk WebKit is running correctly on x64 macOS (iMac Pro).
@Kleis Can you take a look?
Comment 4 Yusuke Suzuki 2024-08-26 14:38:04 PDT
Created attachment 472305 [details]
Test on iMac Pro x64
Comment 5 Kleis Auke Wolthuizen 2024-08-27 00:23:06 PDT
Great! I can confirm that the issue is resolved in WebKitGTK 2.45.90 on Fedora Rawhide, indicating that the fix was landed within this revision range:
https://github.com/WebKit/WebKit/compare/webkitgtk-2.45.6...webkitgtk-2.45.90

Feel free to perform a git bisect if further pinpointing is needed, but I'll proceed with closing this issue for now.

Apologies for not providing a minimal reproducible example initially - the project involves Emscripten's dynamic linking and pthreads functionality, making it difficult to create a standalone reproducer.
https://emscripten.org/docs/compiling/Dynamic-Linking.html#pthreads-support
Comment 6 Yusuke Suzuki 2024-08-27 09:00:34 PDT
(In reply to Kleis Auke Wolthuizen from comment #5)
> Great! I can confirm that the issue is resolved in WebKitGTK 2.45.90 on
> Fedora Rawhide, indicating that the fix was landed within this revision
> range:
> https://github.com/WebKit/WebKit/compare/webkitgtk-2.45.6...webkitgtk-2.45.90
> 
> Feel free to perform a git bisect if further pinpointing is needed, but I'll
> proceed with closing this issue for now.
> 
> Apologies for not providing a minimal reproducible example initially - the
> project involves Emscripten's dynamic linking and pthreads functionality,
> making it difficult to create a standalone reproducer.
> https://emscripten.org/docs/compiling/Dynamic-Linking.html#pthreads-support

Nice! Thank you so much for confirmation, and thank you for your report!!!