Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3cb52d84eeb3e3f1d64b4aa963ec2da521a9bfdb
https://github.com/WebKit/WebKit/commit/3cb52d84eeb3e3f1d64b4aa963ec2da521a9bfdb
Author: Jean-Yves Avenard <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/WebCore/Modules/mediasource/MediaSource.cpp
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
WebCore::MediaSource::~MediaSource; WebCore::MediaSource::~MediaSource;
mpark::detail::destructor::~destructor
https://bugs.webkit.org/show_bug.cgi?id=301674
rdar://163479310
Reviewed by Jer Noble.
In 285110@main, we handled the case where the MediaSource object would be
destructed and the attempt to ref itself, causing an assertion. 285110@main
handled the case where the resource selection algorithm had already run
and HTMLMediaElement::m_mediaSource would have already been set.
It is apparently possible however, for the HTMLMediaElement to be GCed before
the
resource selection algorithm got to run, in which case the MediaSource reference
is hold in HTMLMediaElement::m_mediaProvider hold the MediaSource.
For this to occur, the HTMLMediaElement to which we just set the srcObj
attribute
must be GCed within that same runloop.
We now handle such case.
Additionally we exit early in MediaSource::detachFromElement if the MediaSource
is no yet or no longer attached to any element, which allows to call this
method multiple times on the same MediaSource object.
* Source/WebCore/Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::detachFromElement):
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::~HTMLMediaElement):
Originally-landed-as: 301765.208@safari-7623-branch (4c366859c744).
rdar://166337132
Canonical link: https://commits.webkit.org/304402@main
Commit: 1025bd18c9c7bd3d5b35f88f5926ae7e8feb8796
https://github.com/WebKit/WebKit/commit/1025bd18c9c7bd3d5b35f88f5926ae7e8feb8796
Author: Daniel Liu <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
Log Message:
-----------
CodeBlock jettison should deref, rather than reset, StructureStubInfo
https://bugs.webkit.org/show_bug.cgi?id=301726
rdar://162487754
Reviewed by Yusuke Suzuki and Mark Lam.
Other CodeBlocks may still be referring to that StructureStubInfo, thus
we cannot just blindly reset it. Instead, we'll deref it, which updates
the reference count to indicate we're no longer using it.
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
Originally-landed-as: 301765.223@safari-7623-branch (178c4858a787).
rdar://166336835
Canonical link: https://commits.webkit.org/304403@main
Commit: 7c0f5e8d5531e0729dee99d81743b9864c1d6f44
https://github.com/WebKit/WebKit/commit/7c0f5e8d5531e0729dee99d81743b9864c1d6f44
Author: Qianlang Chen <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm
Log Message:
-----------
com.apple.WebKit.WebContent at com.apple.WebCore:
WebCore::ResourceUsageThread::platformCollectCPUData
https://bugs.webkit.org/show_bug.cgi?id=301716
rdar://140592689
Reviewed by Abrar Rahman Protyasha.
In https://commits.webkit.org/209170@main, we improved the
categorization of the threads shown in the CPU profiler. To identify
a thread as used by WebKit, we rely on a set of heuristics, one of them
being the thread's current dispatch queue's name. This required first
dereferencing a dispatch_queue_t*, which is unsafe given the queue may
be destroyed concurrently.
Given there appears to be no safe alternative way of getting the queue's
name, remove the retrieval and therefore the check using it. This means
a good portion of WebKit-related threads will still be discovered and
categorized, except for those temporarily-borrowed with the Grand
Central Dispatch, which will start to be labeled as unknown/other
threads. Given the severity and frequency of the crash due to the unsafe
dereferencing, I believe it's worth it to prevent it at the expense of
the reduced functionality, and find a way to safely implement it later
(https://webkit.org/b/301777).
No new tests. The special behavior that this patch removed was not
not covered by tests, so no tests should be broken. The basic thread
identification is covered by existing tests
inspector/cpu-profiler/{threads,tracking}.html,
which should continue to pass.
* Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm:
(WebCore::threadInfos):
(WebCore::ResourceUsageThread::platformCollectCPUData):
Originally-landed-as: 301765.247@safari-7623-branch (97d718c3ff9a).
rdar://166336640
Canonical link: https://commits.webkit.org/304404@main
Commit: 05aaac31df25b1abf015b35c0fd0900904b2b264
https://github.com/WebKit/WebKit/commit/05aaac31df25b1abf015b35c0fd0900904b2b264
Author: Per Arne Vollan <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/WebKit/NetworkProcess/cocoa/NetworkProcessCocoa.mm
Log Message:
-----------
ARQuickLook HTML banner fails to render
https://bugs.webkit.org/show_bug.cgi?id=301865
rdar://163899118
Reviewed by Sihui Liu.
If the sandbox in the UI process is blocking network access, the Networking
process sandbox inherits this property.
This change prevents ARQuickLook from rendering HTML banners. This issue can be
resolved by making an exemption for
platform binaries.
* Source/WebKit/NetworkProcess/cocoa/NetworkProcessCocoa.mm:
(WebKit::NetworkProcess::platformInitializeNetworkProcessCocoa):
Originally-landed-as: 301765.248@safari-7623-branch (5eb90b01bff3).
rdar://166336525
Canonical link: https://commits.webkit.org/304405@main
Commit: 39a5ac27139893e6369b2b491c0ec29e816eac5d
https://github.com/WebKit/WebKit/commit/39a5ac27139893e6369b2b491c0ec29e816eac5d
Author: Dan Hecht <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.h
M Source/bmalloc/libpas/src/test/ExpendableMemoryTests.cpp
Log Message:
-----------
[libpas] fix lock-free reads of the medium directory tuple table
https://bugs.webkit.org/show_bug.cgi?id=301940
rdar://163964480
Reviewed by Yusuke Suzuki and Keith Miller.
Some paths read the medium directory tuple table using a lock-free
algorithm. However, they return a pointer into this table and
load from the pointer after checking for mutations to the table,
potentially reading the wrong entry.
Fix this by performing the read in the lock free critical section
(unless the heap lock is held along the path, in which case the pointer
is still used).
Thanks to Phil Pizlo for finding the issue and proposing the fix.
Testing: added asserts to verify this race condition
* Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h:
(pas_local_allocator_try_allocate):
* Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c:
(medium_directory_tuple_for_index_impl):
(medium_directory_tuple_for_index_with_lock):
(pas_segregated_heap_medium_directory_tuple_for_index):
(pas_segregated_heap_medium_allocator_index_for_index):
(pas_segregated_heap_medium_size_directory_for_index):
(pas_segregated_heap_ensure_allocator_index):
(pas_segregated_heap_ensure_size_directory_for_size):
* Source/bmalloc/libpas/src/libpas/pas_segregated_heap.h:
(pas_segregated_heap_medium_directory_result_create_empty):
Originally-landed-as: 301765.261@safari-7623-branch (1164239a5354).
rdar://166336234
Canonical link: https://commits.webkit.org/304406@main
Compare: https://github.com/WebKit/WebKit/compare/b26db034dbb9...39a5ac271398
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
