Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 3ebc4f5079f680485ce8222289a2ba8219cd42a0
https://github.com/WebKit/WebKit/commit/3ebc4f5079f680485ce8222289a2ba8219cd42a0
Author: Carlos Alberto Lopez Perez <[email protected]>
Date: 2026-08-04 (Tue, 04 Aug 2026)
Changed paths:
M Source/JavaScriptCore/runtime/VM.cpp
Log Message:
-----------
Cherry-pick 318487@main (bff3814d76f7).
https://bugs.webkit.org/show_bug.cgi?id=320559
[JSC][Linux] Don't re-read /proc/self/maps when handling checkpoint OSR
side state
https://bugs.webkit.org/show_bug.cgi?id=320559
Reviewed by Yusuke Suzuki and Justin Michaud.
VM::pushCheckpointOSRSideState() has an ASSERT_ENABLED block that checks
that the side state stack remains ordered. To do so, it needs the current
thread stack bounds.
It obtained them using StackBounds::currentThreadStackBounds(), which does
not cache the result. On Linux, this calls pthread_getattr_np(), which glibc
implements for the main thread by opening and parsing /proc/self/maps.
Each call makes the kernel generate a list of the process memory mappings
and then makes glibc parse that list.
While running wasm/stress/type-index-abstract-heap-types-nulls-and-casts.js
in wasm-eager mode, profiling showed about ~45% of samples in kernel code
generating /proc/self/maps and another ~30% in libc parsing it. The test
opened /proc/self/maps hundreds of times through repeated calls to
VM::pushCheckpointOSRSideState().
Thread::m_stack is initialized using StackBounds::currentThreadStackBounds()
and cached for the lifetime of the thread.
Thread::currentSingleton().stack()
therefore provides the cached bounds without repeating the OS query.
logSanitizeStack() in the same file already uses this cached value.
Switch both call sites in VM.cpp to the cached bounds. This keeps the
relevant stack consistency assertions checks without asking the operating
system to recalculate information that the thread already stores.
popAllCheckpointOSRSideStateUntil() is not assertion-only: it uses the
bounds as part of its normal operation. This change therefore also avoids
the same cost in release builds.
With this change, on a Release+Asserts WPE build, `run-jsc-stress-tests \
--filter wasm.yaml/wasm/stress/type-index-abstract-heap-types` completes
in about five minutes. Previously, it could take around one hour, and the
tests would usually time out.
*
JSTests/wasm/stress/type-index-abstract-heap-types-concrete-vs-abstract.js:
* JSTests/wasm/stress/type-index-abstract-heap-types-globals-and-tables.js:
* JSTests/wasm/stress/type-index-abstract-heap-types-nulls-and-casts.js:
* JSTests/wasm/stress/type-index-abstract-heap-types-subtype-validation.js:
* Source/JavaScriptCore/runtime/VM.cpp:
(JSC::VM::pushCheckpointOSRSideState):
(JSC::VM::popAllCheckpointOSRSideStateUntil):
Canonical link: https://commits.webkit.org/318487@main
Canonical link: https://commits.webkit.org/305877.1026@webkitglib/2.52
Commit: c0d330aff5ed6562e75a220ce1de0f88809a970e
https://github.com/WebKit/WebKit/commit/c0d330aff5ed6562e75a220ce1de0f88809a970e
Author: Anthony Tarbinian <[email protected]>
Date: 2026-08-04 (Tue, 04 Aug 2026)
Changed paths:
A
ManualTests/webaudio/nocrash-audiocontext-reference-destroyed-document.html
M Source/WebCore/Modules/webaudio/AudioContext.cpp
M Source/WebCore/Modules/webaudio/AudioContext.h
M Source/WebCore/Modules/webaudio/BaseAudioContext.h
Log Message:
-----------
Cherry-pick 313630@main (ed04ff40674d).
https://bugs.webkit.org/show_bug.cgi?id=309708
Don't call document->removeAudioProducer during Document destruction
https://bugs.webkit.org/show_bug.cgi?id=309708
rdar://172168772
Reviewed by Ryosuke Niwa.
When the Document destructor is called, it is possible
for it to take a code path where it references the document
which is actively being destroyed. Since the Document is
in the middle of it's destructor call, the Document is not in
a well-defined state it may have already freed member variables, etc.
This is the path which leads to the access of the document during
destruction:
- Document::~Document
- ScriptExecutionContext::~ScriptExecutionContext
- BaseAudioContext::deleteMarkedNodes
- AudioContext::~AudioContext
- Document::removeAudioProducer
To remove the audio producers safely, this patch does so when we are certain
the document is still alive. So, we will call this from AudioContext::stop()
which itself gets invoked from Document::commonTeardown ->
ScriptExectionContext::stopActiveDOMObjects.
To be defensive, we can also guard the call to
document->removeAudioProducer in
~AudioContext with a check to !BaseAudioContext::isStopped().
This ensures that we won't access the document while it is being torn down.
During teardown, ScriptExecutionContext will stop the AudioContext by
calling BaseAudioContext::stop which in turn sets
BaseAudioContext::m_isStopScheduled to true and causes
BaseAudoContext::isStopped to return true.
Adding a manual test since the layout test can take up to a few
minutes to trigger the bug.
If running the manual test, test it against an ASAN build to reproduce
the crash. On average, the test takes 49 seconds to trigger the bug.
*
ManualTests/webaudio/nocrash-audiocontext-reference-destroyed-document.html:
Added.
* Source/WebCore/Modules/webaudio/AudioContext.cpp:
(WebCore::AudioContext::~AudioContext):
(WebCore::AudioContext::stop):
* Source/WebCore/Modules/webaudio/AudioContext.h:
* Source/WebCore/Modules/webaudio/BaseAudioContext.h:
Originally-landed-as: 305413.492@rapid/safari-7624.2.5.110-branch
(72b0f61b5005). rdar://176061965
Canonical link: https://commits.webkit.org/313630@main
Canonical link: https://commits.webkit.org/305877.1027@webkitglib/2.52
Commit: 4ced87c7f06e836663f66ffdec193d765be636d0
https://github.com/WebKit/WebKit/commit/4ced87c7f06e836663f66ffdec193d765be636d0
Author: Eric Carlson <[email protected]>
Date: 2026-08-04 (Tue, 04 Aug 2026)
Changed paths:
A
LayoutTests/platform/mac/media/webaudio-session-removed-when-frame-is-destroyed-expected.txt
A
LayoutTests/platform/mac/media/webaudio-session-removed-when-frame-is-destroyed.html
M Source/WebCore/Modules/webaudio/AudioContext.cpp
Log Message:
-----------
Cherry-pick 318283@main (9f60bad504c7).
https://bugs.webkit.org/show_bug.cgi?id=320689
[WebAudio] AudioContext leaves its media session registered after frame
teardown
https://bugs.webkit.org/show_bug.cgi?id=320689
rdar://183672900
Reviewed by Jean-Yves Avenard.
AudioContext::stop() (document/frame teardown) stopped the audio thread but
never removed the
context's PlatformMediaSession -- unlike close(), it left the session
registered with the manager
until the context was garbage-collected, keeping the audio session (and
NowPlaying) alive on behalf
of a context whose frame was already gone.
Remove the media session in stop(), mirroring close(). setActive(false) is
a no-op if the context
never activated.
Test:
platform/mac/media/webaudio-session-removed-when-frame-is-destroyed.html
*
LayoutTests/platform/mac/media/webaudio-session-removed-when-frame-is-destroyed-expected.txt:
Added.
*
LayoutTests/platform/mac/media/webaudio-session-removed-when-frame-is-destroyed.html:
Added.
* Source/WebCore/Modules/webaudio/AudioContext.cpp:
(WebCore::AudioContext::stop):
Canonical link: https://commits.webkit.org/318283@main
Canonical link: https://commits.webkit.org/305877.1028@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/8fc3e4613a57...4ced87c7f06e
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
