Changeset 285191 in webkit

Timestamp:

Nov 2, 2021, 6:27:28 PM (5 years ago)

Author:

rmorisset@apple.com

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:

Location:

trunk

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• LayoutTests/platform/mac-wk1/TestExpectations (modified) (1 diff)
• Source/WebCore/ChangeLog (modified) (1 diff)
• Source/WebCore/Modules/webaudio/AudioBuffer.cpp (modified) (2 diffs)
• Source/WebCore/Modules/webaudio/AudioBuffer.h (modified) (1 diff)

trunk/LayoutTests/ChangeLog

@@ +1 @@
+2021-11-02  Robin Morisset  <rmorisset@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  <tyler_w@apple.com>
 

trunk/LayoutTests/platform/mac-wk1/TestExpectations

@@ -1386 +1386 @@
 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 ]
 

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2021-11-02  Robin Morisset  <rmorisset@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.olmstead@sony.com>
 

trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp

@@ -87 +87 @@
     , m_isDetachable(preventDetaching == LegacyPreventDetaching::No)
 {
+    if (static_cast<uint64_t>(m_originalLength) > s_maxLength) {
+        invalidate();
+        return;
+    }
+
     m_channels.reserveCapacity(numberOfChannels);
 
@@ -108 +113 @@
     , 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();

trunk/Source/WebCore/Modules/webaudio/AudioBuffer.h

@@ -93 +93 @@
     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;