Title: [285191] trunk
- Revision
- 285191
- Author
- rmoris...@apple.com
- Date
- 2021-11-02 18:27:28 -0700 (Tue, 02 Nov 2021)
Log Message
Regression (r284330): [ macOS wk1 Debug ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
https://bugs.webkit.org/show_bug.cgi?id=232244
<rdar://problem/84616427>
Reviewed by Yusuke Suzuki.
Source/WebCore:
The test is verifying that trying to allocate an AudioBuffer with 4GB channels fails cleanly.
It used to work automatically, as AudioBuffer relies on Float32Array under the hood, which was limited to 2GB.
Since r284330, ArrayBuffers can be up to 4GB, so it now takes very long to OOM, and sometimes timeout.
I use the same solution which I used for PixelBuffers in r284330: just test that the length is reasonable
and if it is not then abort as if the allocation of the Float32Array had failed.
No new tests: covered by LayoutTests/webaudio/AudioBuffer/huge-buffer.html
* Modules/webaudio/AudioBuffer.cpp:
(WebCore::AudioBuffer::AudioBuffer):
* Modules/webaudio/AudioBuffer.h:
LayoutTests:
* platform/mac-wk1/TestExpectations:
Modified Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (285190 => 285191)
--- trunk/LayoutTests/ChangeLog 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/LayoutTests/ChangeLog 2021-11-03 01:27:28 UTC (rev 285191)
@@ -1,3 +1,13 @@
+2021-11-02 Robin Morisset <rmoris...@apple.com>
+
+ Regression (r284330): [ macOS wk1 Debug ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
+ https://bugs.webkit.org/show_bug.cgi?id=232244
+ <rdar://problem/84616427>
+
+ Reviewed by Yusuke Suzuki.
+
+ * platform/mac-wk1/TestExpectations:
+
2021-11-02 Tyler Wilcock <tyle...@apple.com>
AX: WebKit needs to include NSAccessibilityChildrenInNavigationOrderAttribute in accessibilityAttributeNames
Modified: trunk/LayoutTests/platform/mac-wk1/TestExpectations (285190 => 285191)
--- trunk/LayoutTests/platform/mac-wk1/TestExpectations 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/LayoutTests/platform/mac-wk1/TestExpectations 2021-11-03 01:27:28 UTC (rev 285191)
@@ -1385,8 +1385,6 @@
webkit.org/b/228796 [ BigSur+ ] webaudio/silent-audio-interrupted-in-background.html [ Pass Timeout ]
webkit.org/b/228796 [ Catalina Debug ] webaudio/silent-audio-interrupted-in-background.html [ Pass Timeout ]
-webkit.org/b/232244 [ Debug ] webaudio/AudioBuffer/huge-buffer.html [ Pass Timeout ]
-
webkit.org/b/227136 media/video-pause-immediately.html [ Pass Failure ]
webkit.org/b/228084 [ BigSur Release ] media/video-restricted-no-preload-auto.html [ Pass Failure ]
Modified: trunk/Source/WebCore/ChangeLog (285190 => 285191)
--- trunk/Source/WebCore/ChangeLog 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/Source/WebCore/ChangeLog 2021-11-03 01:27:28 UTC (rev 285191)
@@ -1,3 +1,23 @@
+2021-11-02 Robin Morisset <rmoris...@apple.com>
+
+ Regression (r284330): [ macOS wk1 Debug ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
+ https://bugs.webkit.org/show_bug.cgi?id=232244
+ <rdar://problem/84616427>
+
+ Reviewed by Yusuke Suzuki.
+
+ The test is verifying that trying to allocate an AudioBuffer with 4GB channels fails cleanly.
+ It used to work automatically, as AudioBuffer relies on Float32Array under the hood, which was limited to 2GB.
+ Since r284330, ArrayBuffers can be up to 4GB, so it now takes very long to OOM, and sometimes timeout.
+ I use the same solution which I used for PixelBuffers in r284330: just test that the length is reasonable
+ and if it is not then abort as if the allocation of the Float32Array had failed.
+
+ No new tests: covered by LayoutTests/webaudio/AudioBuffer/huge-buffer.html
+
+ * Modules/webaudio/AudioBuffer.cpp:
+ (WebCore::AudioBuffer::AudioBuffer):
+ * Modules/webaudio/AudioBuffer.h:
+
2021-11-02 Don Olmstead <don.olmst...@sony.com>
SVG elements should include SVGElementInlines not ElementInlines
Modified: trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp (285190 => 285191)
--- trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp 2021-11-03 01:27:28 UTC (rev 285191)
@@ -86,6 +86,11 @@
, m_originalLength(length)
, m_isDetachable(preventDetaching == LegacyPreventDetaching::No)
{
+ if (static_cast<uint64_t>(m_originalLength) > s_maxLength) {
+ invalidate();
+ return;
+ }
+
m_channels.reserveCapacity(numberOfChannels);
for (unsigned i = 0; i < numberOfChannels; ++i) {
@@ -107,6 +112,11 @@
: m_sampleRate(bus.sampleRate())
, m_originalLength(bus.length())
{
+ if (static_cast<uint64_t>(m_originalLength) > s_maxLength) {
+ invalidate();
+ return;
+ }
+
// Copy audio data from the bus to the Float32Arrays we manage.
unsigned numberOfChannels = bus.numberOfChannels();
m_channels.reserveCapacity(numberOfChannels);
Modified: trunk/Source/WebCore/Modules/webaudio/AudioBuffer.h (285190 => 285191)
--- trunk/Source/WebCore/Modules/webaudio/AudioBuffer.h 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/Source/WebCore/Modules/webaudio/AudioBuffer.h 2021-11-03 01:27:28 UTC (rev 285191)
@@ -92,6 +92,10 @@
bool hasDetachedChannelBuffer() const;
+ // We do not currently support having the Float32Arrays in m_channels being more than 2GB,
+ // and we have tests that we return an error promptly on trying to create such a huge AudioBuffer.
+ static constexpr uint64_t s_maxLength = (1ull << 32) / sizeof(float);
+
float m_sampleRate;
mutable Lock m_channelsLock;
size_t m_originalLength;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
