Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: f7ec8e813f9e7d3969c3654bf49ced1647af18ff
https://github.com/WebKit/WebKit/commit/f7ec8e813f9e7d3969c3654bf49ced1647af18ff
Author: Anand Srinivasan <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
A JSTests/stress/watchpoint-async-generator-code-deletion.js
A JSTests/stress/watchpoint-closure-not-affected.js
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
Log Message:
-----------
Cherry-pick [email protected] (1af72a6f5454).
https://bugs.webkit.org/show_bug.cgi?id=313499
Pre-invalidate captured-variable WatchpointSets in generator and async
function bodies
https://bugs.webkit.org/show_bug.cgi?id=313499
rdar://173777534
Reviewed by Yusuke Suzuki.
When deleteAllCode runs while an async generator is suspended, the generator
body's CodeBlock is
cleared
and
later
re-created from re-parsed source. The
new CodeBlock's constant pool gets a fresh SymbolTable clone with fresh
WatchpointSets, but the suspended activation still references the original.
A subsequent ResolvedClosureVar put_to_scope on the new CodeBlock fires
touch() against the fresh clone's WatchpointSet, which the DFG is not
watching, so DFG code that constant-folded the captured variable never
deoptimizes and returns stale values.
Treat ResolvedClosureVar writes inside suspendable bodies the same way
ClosureVar writes are already treated: invalidate the WatchpointSet at
link time. Sibling closures using ClosureVar already pay this cost;
extending it to the declaring function eliminates the only remaining
runtime path that relies on SymbolTable identity across re-link.
Tests: JSTests/stress/watchpoint-async-generator-code-deletion.js
JSTests/stress/watchpoint-closure-not-affected.js
*
JSTests/stress/watchpoint-async-generator-code-deletion.js: Added.
(async sleepAsync):
(async main.opt):
(async main):
* JSTests/stress/watchpoint-closure-not-affected.js: Added.
(async sleepAsync):
(async test.):
(async test.obj):
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=DB1C6o3pt9&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE3Njk1LjIzMUB3ZWJraXRnbGliLzIuNTQ=&emid=c89f0764-a80b-4517-b2f5-75e210c9168e&c=11
Commit: e3b53c7b445e17b565ee7221133e5d15d17792b9
https://github.com/WebKit/WebKit/commit/e3b53c7b445e17b565ee7221133e5d15d17792b9
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
M Source/WebCore/platform/graphics/PixelBufferConversion.cpp
Log Message:
-----------
Cherry-pick
[email protected] (e66d0b93bf1f).
https://bugs.webkit.org/show_bug.cgi?id=316131
Converting Float16 pixels buffers to
Unpremultiplied
or
premultiplied may miss the last row
https://bugs.webkit.org/show_bug.cgi?id=316131
rdar://177764433
Reviewed by Gerald Squelart.
convertImagePixelsFromFloat16ToFloat16() was written with the wrong
assumption.
The calculations in this function assume the source and destination
PixelBuffers
are rectangular. But sometimes they are not.
ImageBufferBackend::getPixelBuffer()
and ImageBufferBackend::putPixelBuffer() get subspans from the source and
destination PixelBuffers starting from the starting point till the end of
these
PixelBuffers. The bytesPerRow of the PixelBuffer and
PixelBufferConversionView
may be larger than the bytesPerRow of the requested PixelBuffer.
Like what other conversion functions do, the solution is not to drive the
width
and the height of
sourceBuffer and destinationBuffer from the size_bytes and the
bytesPerRow. The fix is to convert destinationBytesPerRow pixels from the
sourceBuffer
into
the destinationBuffer for every row. To get the starting pixel
for the next row from the sourceBuffer, we need to move by
sourceBytesPerRow.
* Source/WebCore/platform/graphics/PixelBufferConversion.cpp:
(WebCore::convertImagePixelsFromFloat16ToFloat16):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=Dm7m6h3vt1&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE3Njk1LjIzMkB3ZWJraXRnbGliLzIuNTQ=&emid=c89f0764-a80b-4517-b2f5-75e210c9168e&c=11
Commit: 335d74b316363bddb15644766dd16e5f18181ce3
https://github.com/WebKit/WebKit/commit/335d74b316363bddb15644766dd16e5f18181ce3
Author: Keith Miller <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
A
JSTests/stress/arguments-elimination-inlined-load-varargs-preserves-recoveries.js
A
JSTests/stress/arguments-elimination-load-varargs-kills-promoted-recoveries.js
M
Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp
M Source/JavaScriptCore/dfg/DFGCombinedLiveness.cpp
M Source/JavaScriptCore/dfg/DFGCombinedLiveness.h
M
Source/JavaScriptCore/dfg/DFGForAllKills.h
M Source/JavaScriptCore/dfg/DFGOSRAvailabilityAnalysisPhase.cpp
Log Message:
-----------
Cherry-pick [email protected] (6c004fb89bd7).
https://bugs.webkit.org/show_bug.cgi?id=318348
OSR Availability Fails to Invalidate Local Recoveries Across LoadVarargs
https://bugs.webkit.org/show_bug.cgi?id=318348
rdar://178255543
Reviewed by Yusuke Suzuki.
When a strict-mode `arguments` allocation produced by an inlined varargs
call
is eliminated to PhantomClonedArguments, OSR availability records each
argument
as a promoted heap location
backed by the inlined frame's stack slots. A second
inlined varargs call that lowers to LoadVarargs may reuse those same virtual
registers. If an OSR exit later
materialises the first allocation it must not
do so from those reused slots.
Two independent invariants were violated:
1.
LocalOSRAvailabilityCalculator::executeNode() handles PutStack/KillStack by
calling killHeaps() before replacing a stack operand's availability so
that
any promoted heap location flushed to that operand is invalidated. The
LoadVarargs / ForwardVarargs case replaced the count and argument
operands
without that invalidation, leaving stale promoted recoveries pointing at
the
overwritten slots. Apply the same killHeaps() calls before each
replacement.
2. DFG arguments-elimination interference analysis must disqualify a
candidate
whose source-frame stack slots are clobbered while the candidate is still
OSR-live. It
establishes the candidate's live range using
forAllKilledNodesAtNodeIndex() plus CombinedLiveness::liveAtTail.
liveAtTail was computed only as the union of CFG
successors' liveAtHead,
each of which is pruned by bytecode liveness at the successor's first
node.
A candidate that
is
OSR-live at the block's terminal node but whose
backing local is bytecode-dead at every CFG successor e.g.
```
// block 1
let a = ...;
try {
foo();
} catch (e) {
// block 2
use(a);
}
// block 3
```
Since DFG does not directly model exceptional control flow in the CFG
`a` would be absent from the CFG/bytecode at block 3 and therefore absent
from block 1's liveAtTail, so removeViaKill() would never be called on
`a`.
Note: For 2, we don't include the bytecodeLiveness for the tail of
CombinedLiveness
because this is both misleading with respect to how tail is
used in the rest of the DFG. Additionally, it breaks
ObjectAllocationSinking.
ObjectAllocationSinking
propagates its heap by pruning at each tail with
liveAtTail then merging into successors. Since we don't prune at the head we
can
end up pushing phantom allocations into blocks where they don't actually
dominate.
Tests:
JSTests/stress/arguments-elimination-inlined-load-varargs-preserves-recoveries.js
JSTests/stress/arguments-elimination-load-varargs-kills-promoted-recoveries.js
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=DA2G6P9Ig7&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE3Njk1LjIzM0B3ZWJraXRnbGliLzIuNTQ=&emid=c89f0764-a80b-4517-b2f5-75e210c9168e&c=11
Commit: 5b71f92830610b9f973e272126e97806e1ec43f9
https://github.com/WebKit/WebKit/commit/5b71f92830610b9f973e272126e97806e1ec43f9
Author: Jean-Yves
Avenard <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
A
LayoutTests/webaudio/AudioParam/audioparam-cross-thread-ref-deref-crash-expected.txt
A
LayoutTests/webaudio/AudioParam/audioparam-cross-thread-ref-deref-crash.html
Log Message:
-----------
Cherry-pick
[email protected] (62fcbfe61a49).
https://bugs.webkit.org/show_bug.cgi?id=318405
use-after-free of AudioParam via cross-thread non-atomic ref/deref in
AudioNodeOutput::disconnectAllParams()
rdar://177930032
Reviewed by Youenn Fablet.
Make AudioParam use thread-safe refcounted.
Test: webaudio/AudioParam/audioparam-cross-thread-ref-deref-crash.html
*
LayoutTests/webaudio/AudioParam/audioparam-cross-thread-ref-deref-crash-expected.txt:
Added.
*
LayoutTests/webaudio/AudioParam/audioparam-cross-thread-ref-deref-crash.html:
Added.
* Source/WebCore/Modules/webaudio/AudioParam.h:
Identifier:
[email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=dr0e0l8CX1&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE3Njk1LjIzNEB3ZWJraXRnbGliLzIuNTQ=&emid=c89f0764-a80b-4517-b2f5-75e210c9168e&c=11
Compare: https://github.com/WebKit/WebKit/compare/2b0366caa044...5b71f9283061
To
unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
