Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b5148db1c4c10cfd8cdeb2c33c0b26fc1b4223d3
https://github.com/WebKit/WebKit/commit/b5148db1c4c10cfd8cdeb2c33c0b26fc1b4223d3
Author: Vassili Bykov <[email protected]>
Date: 2025-09-18 (Thu, 18 Sep 2025)
Changed paths:
A JSTests/wasm/gc-spec-harness/wasm-module-builder.js
A JSTests/wasm/regress/298930.js
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
M Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.cpp
M Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.h
Log Message:
-----------
Avoid a validation failure while creating a Wasm array with array.new_elem
https://bugs.webkit.org/show_bug.cgi?id=298930
rdar://160674746
Reviewed by Yusuke Suzuki.
'arrayNewElem' creates the array in two stages: first it creates an array full
of null
values, then these transient nulls are replaced with the final values. The
problem is that
in the second stage the array is already exposed to GC. If the "official"
element type of
the array is not nullable and assertions are enabled, GC validates array
contents and the
transient null values cause a failure.
The patch fixes this by adding a flag to JSWebAssemblyArray (if assertions are
enabled).
The flag is set by 'arrayNewElem' until the array is fully populated with the
final
values. Validation code skips an array if it has the flag set.
Even when enabled, the flag does not increase the size of JSWebAssemblyArray.
That class
currently has 4 bytes of padding at the end of the object (implicit on 64-bit
systems and
explicit on 32-bit). When the flag is enabled, it takes one of those unused
bytes.
The patch also adds a GC-aware WasmModuleBuilder required by the tests.
Canonical link: https://commits.webkit.org/300181@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
