Branch: refs/heads/webkitglib/2.48
Home: https://github.com/WebKit/WebKit
Commit: d13915aec992a32448b7384af58f6c68ce3e7050
https://github.com/WebKit/WebKit/commit/d13915aec992a32448b7384af58f6c68ce3e7050
Author: Szymon Witamborski <[email protected]>
Date: 2025-06-16 (Mon, 16 Jun 2025)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.html
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.js
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker.html
M Source/WebCore/platform/audio/cocoa/PlatformRawAudioDataCocoa.cpp
M Source/WebCore/platform/audio/gstreamer/PlatformRawAudioDataGStreamer.cpp
Log Message:
-----------
Cherry-pick 296217@main (e1a2977e3a83).
https://bugs.webkit.org/show_bug.cgi?id=291070
Fix AudioData.copyTo crashing on memcpy
https://bugs.webkit.org/show_bug.cgi?id=291070
Reviewed by Philippe Normand and Jean-Yves Avenard.
The memcpy branch of both GStreamer and Cocoa implementations were
not taking into account copyElementCount when calculating subSource.
This was causing overwriting the target if there was enough space
and crashes if the target was just-sized for the requested number
of elements to copy.
Moreover, only mono case for planar data was using memcpy while
stereo was using the unoptimised route. This was inconsistent with
the interleaved mode which was using memcpy for any number of
channels.
Add tests for mono, stereo, planar and interleaved data. Fix writing
beyond requested range and crashes by:
- taking into account copyElementCount when calulating subSource
- taking into account frame size when calculating frameOffsetInBytes
- taking into account sample size when calculating copyLengthInBytes
To unify handling of multichannel data between planar and interleaved
modes, enumerate more cases where it's safe to use memcpy and handle
the stereo planar case by adding a plane offset to the frame offset.
It's worth mentioning differences between GStreamer and Cocoa
implementations. While GST_AUDIO_INFO_BPF ("bytes per frame")
consistenly returns sampleSize * numberOfChannels, Cocoa's
CAAudioStreamDescription::bytesPerFrame() will be only multiplied
by number of channels in interleaved mode. Hence slight differences
in the way frame size and sample size are calculated in each
implementation.
It's also worth mentioning for context that copyElementCount is the
original options.frameCount already multiplied by number of channels
in case of interleaved copy. So copyLengthInBytes needs to only be
calculated from sample size, not the frame size.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.js:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker.html:
Added.
* Source/WebCore/platform/audio/cocoa/PlatformRawAudioDataCocoa.cpp:
(WebCore::PlatformRawAudioData::copyTo): Fixed writing out of bounds and
crashes.
* Source/WebCore/platform/audio/gstreamer/PlatformRawAudioDataGStreamer.cpp:
(WebCore::PlatformRawAudioData::copyTo): Fixed writing out of bounds and
crashes.
Canonical link: https://commits.webkit.org/296217@main
Canonical link: https://commits.webkit.org/290945.249@webkitglib/2.48
Commit: a204bfb6dfd1d15571d3dd5e4f9311e35aab0883
https://github.com/WebKit/WebKit/commit/a204bfb6dfd1d15571d3dd5e4f9311e35aab0883
Author: Ahmad Saleem <[email protected]>
Date: 2025-06-16 (Mon, 16 Jun 2025)
Changed paths:
M Source/WebCore/svg/SVGTextPathElement.cpp
Log Message:
-----------
Cherry-pick 296202@main (f3fb9be8c17f).
https://bugs.webkit.org/show_bug.cgi?id=294432
[LBSE] Fix `textPath` test crashes post 283675@main
https://bugs.webkit.org/show_bug.cgi?id=294432
rdar://153269819
Reviewed by Simon Fraser.
This patch is to address crashes in 'textPath' SVG tests on LBSE
implementation,
it seems to be introduced by 283675@main, where the change didn't handled
LBSE part leading to crashes. This patch just early return in case of LBSE
case.
I confirmed while trying to generate 'Tahoe' expectations for LBSE that it
does
fix all crashes for 'textPath' SVG tests.
* Source/WebCore/svg/SVGTextPathElement.cpp:
(WebCore::SVGTextPathElement::buildPendingResource):
Canonical link: https://commits.webkit.org/296202@main
Canonical link: https://commits.webkit.org/290945.250@webkitglib/2.48
Compare: https://github.com/WebKit/WebKit/compare/e9ed7cbd66e7...a204bfb6dfd1
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
