Branch: refs/heads/webkitglib/2.50
Home: https://github.com/WebKit/WebKit
Commit: 266ef7e51ef76bbeb304d7396632d25415d25282
https://github.com/WebKit/WebKit/commit/266ef7e51ef76bbeb304d7396632d25415d25282
Author: Sosuke Suzuki <[email protected]>
Date: 2026-03-18 (Wed, 18 Mar 2026)
Changed paths:
A JSTests/stress/typedarray-sort-buffer-access-stale-pointer.js
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h
Log Message:
-----------
Cherry-pick 308833@main (b9c004b3c5be).
https://bugs.webkit.org/show_bug.cgi?id=309346
[JSC] `TypedArray#sort` fails when comparator access `.buffer`
https://bugs.webkit.org/show_bug.cgi?id=309346
Reviewed by Yusuke Suzuki.
When sorting a FastTypedArray with a comparator, accessing `.buffer` inside
the comparator triggers slowDownAndWasteMemory(), which reallocates the
backing store into a new ArrayBuffer and updates m_vector. The sort
implementation was caching typedSpan() before invoking the comparator and
writing the sorted result back through this cached span, so the result
never reached the new backing store and the array appeared unsorted.
let ta = new Int32Array(100);
for (let i = 0; i < 100; i++) ta[i] = 100 - i;
ta.sort((a, b) => { ta.buffer; return a - b; });
// ta[0] was 100, should be 1
The isDetached() guard does not help here because the FastTypedArray to
WastefulTypedArray transition is not detachment. Fix by re-fetching
typedSpan() for the write-back. length() was already being re-read at
this point, so this just adds one m_vector load after O(n log n)
comparator calls.
Test: JSTests/stress/typedarray-sort-buffer-access-stale-pointer.js
* JSTests/stress/typedarray-sort-buffer-access-stale-pointer.js: Added.
(shouldBe):
(throw.new.Error):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSortImpl):
Canonical link: https://commits.webkit.org/308833@main
Canonical link: https://commits.webkit.org/298234.512@webkitglib/2.50
Commit: b88cd1449b5943492ba30edada0ab14d293ce87a
https://github.com/WebKit/WebKit/commit/b88cd1449b5943492ba30edada0ab14d293ce87a
Author: Chris Dumez <[email protected]>
Date: 2026-03-21 (Sat, 21 Mar 2026)
Changed paths:
M Source/WTF/wtf/text/StringImpl.cpp
Log Message:
-----------
Cherry-pick 309679@main (1ff4770e5669).
https://bugs.webkit.org/show_bug.cgi?id=310360
Address potential memory leak in StringImpl::reallocateInternal()
https://bugs.webkit.org/show_bug.cgi?id=310360
Reviewed by Darin Adler.
realloc() only frees the memory for this input pointer when it succeeds.
In case of failure, we would return and leak that memory.
Not likely to happen in practice but still a bug.
* Source/WTF/wtf/text/StringImpl.cpp:
(WTF::StringImpl::reallocateInternal):
Canonical link: https://commits.webkit.org/309679@main
Canonical link: https://commits.webkit.org/298234.513@webkitglib/2.50
Commit: e1bbbe36dd790231fa8925ff3fa40a6b183c2a8d
https://github.com/WebKit/WebKit/commit/e1bbbe36dd790231fa8925ff3fa40a6b183c2a8d
Author: Chris Dumez <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/wtf/ThreadSafeWeakPtr.h
Log Message:
-----------
Cherry-pick 309739@main (3a7cb2ff43f8).
https://bugs.webkit.org/show_bug.cgi?id=310500
Fix missing memory fence in
ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr::deref()
https://bugs.webkit.org/show_bug.cgi?id=310500
Reviewed by Keith Miller.
The strong-only deref path used memory_order_relaxed for the CAS that
decrements the ref count. When the count reached zero, the only fence
before object deletion was a seq_cst exchangeOr hidden inside an ASSERT,
meaning it was compiled out in release builds.
Without proper ordering, on ARM, the thread performing the deletion may
not see writes made by other threads before they released their
references, potentially causing the destructor to observe stale state.
Fix this using the standard release/acquire pattern for ref counting:
- Use memory_order_release on the decrement so each thread's writes to
the object are published before its count change becomes visible.
- Add an acquire fence before deletion so the deleting thread
synchronizes with all prior release decrements, making every other
thread's writes visible before the destructor runs.
This matches the pattern used by std::shared_ptr implementations. The
ref() increment correctly remains memory_order_relaxed since the caller
already holds a valid reference.
* Source/WTF/wtf/ThreadSafeWeakPtr.h:
(WTF::ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr::deref const):
Canonical link: https://commits.webkit.org/309739@main
Canonical link: https://commits.webkit.org/298234.514@webkitglib/2.50
Commit: e89434a2ee9f08d83f04b1c166b4b5200dc242d9
https://github.com/WebKit/WebKit/commit/e89434a2ee9f08d83f04b1c166b4b5200dc242d9
Author: Chris Dumez <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/wtf/text/StringParsingBuffer.h
M Tools/TestWebKitAPI/Tests/WTF/StringParsingBuffer.cpp
Log Message:
-----------
Cherry-pick 309749@main (7e2a2b003015).
https://bugs.webkit.org/show_bug.cgi?id=310519
StringParsingBuffer::consume() incorrectly returns the whole buffer
https://bugs.webkit.org/show_bug.cgi?id=310519
Reviewed by Anne van Kesteren.
StringParsingBuffer::consume() incorrectly returns the whole buffer,
instead of just the consumed part.
Test: Tools/TestWebKitAPI/Tests/WTF/StringParsingBuffer.cpp
* Source/WTF/wtf/text/StringParsingBuffer.h:
* Tools/TestWebKitAPI/Tests/WTF/StringParsingBuffer.cpp:
(TestWebKitAPI::TEST(WTF, StringParsingBufferConsumeCount)):
Canonical link: https://commits.webkit.org/309749@main
Canonical link: https://commits.webkit.org/298234.515@webkitglib/2.50
Commit: cc5a899aa63f79b5eb06b89211438bf7beb50f01
https://github.com/WebKit/WebKit/commit/cc5a899aa63f79b5eb06b89211438bf7beb50f01
Author: Chris Dumez <[email protected]>
Date: 2026-03-26 (Thu, 26 Mar 2026)
Changed paths:
M Source/WTF/wtf/Deque.h
M Tools/TestWebKitAPI/Tests/WTF/Deque.cpp
Log Message:
-----------
Cherry-pick 309715@main (18b2f1f3724b).
https://bugs.webkit.org/show_bug.cgi?id=310473
Value returned by Deque::removeAllMatching() is incorrect
https://bugs.webkit.org/show_bug.cgi?id=310473
Reviewed by Darin Adler and Ryosuke Niwa.
The logic was reversed in Deque::removeAllMatching() when computing the
number of items removed. The substraction would underflow.
Test: Tools/TestWebKitAPI/Tests/WTF/Deque.cpp
* Source/WTF/wtf/Deque.h:
* Tools/TestWebKitAPI/Tests/WTF/Deque.cpp:
(TestWebKitAPI::TEST(WTF_Deque, RemoveAllMatching)):
(TestWebKitAPI::TEST(WTF_Deque, RemoveAllMatchingNone)):
(TestWebKitAPI::TEST(WTF_Deque, RemoveAllMatchingAll)):
(TestWebKitAPI::TEST(WTF_Deque, RemoveAllMatchingSingleElement)):
(TestWebKitAPI::TEST(WTF_Deque, RemoveFirstMatching)):
Canonical link: https://commits.webkit.org/309715@main
Canonical link: https://commits.webkit.org/298234.516@webkitglib/2.50
Commit: f051de1b4457428594256fe5fb3f6e1247357e74
https://github.com/WebKit/WebKit/commit/f051de1b4457428594256fe5fb3f6e1247357e74
Author: Adrian Perez de Castro <[email protected]>
Date: 2026-03-30 (Mon, 30 Mar 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp
Log Message:
-----------
Cherry-pick 310202@main (1729470dcaa6).
https://bugs.webkit.org/show_bug.cgi?id=311037
[GTK] SkImage leaked in webkit_favicon_database_get_favicon_finish()
https://bugs.webkit.org/show_bug.cgi?id=311037
Reviewed by Fujii Hironori.
The call to the g_task_propagate_pointer() function used to obtain the
SkImage for a favicon moves the ownership to the caller; but the
reference was not being accounted for. Adopt the reference into a sk_sp
to ensure that it gets dropped at the end of the scope, this avoiding
the leak of the SkImage.
* Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp:
(webkit_favicon_database_get_favicon_finish):
Canonical link: https://commits.webkit.org/310202@main
Canonical link: https://commits.webkit.org/298234.517@webkitglib/2.50
Compare: https://github.com/WebKit/WebKit/compare/cc9a1132a947...f051de1b4457
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
