Bug 240081

Summary:	[ iOS ][ macOS Debug wk1 ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
Product:	WebKit	Reporter:	Karl Rackler <rackler>
Component:	New Bugs	Assignee:	Karl Rackler <rackler>
Status:	RESOLVED CONFIGURATION CHANGED
Severity:	Normal	CC:	cdumez, eric.carlson, webkit-bot-watchers-bugzilla, webkit-bug-importer
Priority:	P2	Keywords:	InRadar
Version:	WebKit Nightly Build
Hardware:	Unspecified
OS:	Unspecified

Description Karl Rackler 2022-05-04 13:57:46 PDT

Description:
webaudio/AudioBuffer/huge-buffer.html

The first timeout that I saw on the dashboard for iOS was 3/24/2022 at r291794. The first timeout that I saw on the dashboard for Big Sur was 2/15/2022 at r289876 and the first timeout that I saw on the dashboard for Monterey was 3/17/2022 at r291422, but neither appear relevant to causing this issue.   This test seems to have been flaky since the start. 

History:
https://results.webkit.org/?suite=layout-tests&test=webaudio%2FAudioBuffer%2Fhuge-buffer.html&platform=ios&platform=mac&limit=50000

Diff:
--- /Volumes/Data/worker/ios-simulator-15-release-gpuprocess-tests-wk2/build/layout-test-results/webaudio/AudioBuffer/huge-buffer-expected.txt
+++ /Volumes/Data/worker/ios-simulator-15-release-gpuprocess-tests-wk2/build/layout-test-results/webaudio/AudioBuffer/huge-buffer-actual.txt
@@ -1,3 +1,5 @@
+FAIL: Timed out waiting for notifyDone to be called
+
 
 PASS # AUDIT TASK RUNNER STARTED.
 PASS Executing "huge buffer"

Comment 1 Radar WebKit Bug Importer 2022-05-04 13:58:03 PDT

<rdar://problem/92752803>

Comment 2 Karl Rackler 2022-05-04 15:32:18 PDT

REPRODUCTION STEPS
I can reproduce this on ToT r293782

Command: 
run-webkit-tests --root 293782 --clobber-old-results --iterations 250 --exit-after-n-crashes-or-timeouts 1 --no-retry-failures --force -f webaudio/AudioBuffer/huge-buffer.html

Result:  
Regressions: Unexpected timeouts (1)
  webaudio/AudioBuffer/huge-buffer.html [ Timeout ]

Comment 3 Karl Rackler 2022-05-04 15:37:31 PDT

I have marked this test as a flaky timeout while this issue is investigated.

Comment 4 Karl Rackler 2022-05-04 15:45:01 PDT

Pull request: https://github.com/WebKit/WebKit/pull/507

Comment 5 EWS 2022-05-04 15:48:00 PDT

Test gardening commit r293796 (250270@main): <https://commits.webkit.org/250270@main>

Reviewed commits have been landed. Closing PR #507 and removing active labels.

Comment 6 Chris Dumez 2022-05-06 13:06:09 PDT

Looks like just a Slow test in Debug, should probably be marked as [Slow] instead of flaky?

Comment 7 Karl Rackler 2022-05-11 07:49:04 PDT

I have marked this test as Slow while this issue is investigated.

Comment 8 Karl Rackler 2022-05-11 07:53:18 PDT

Pull request: https://github.com/WebKit/WebKit/pull/588

Comment 9 EWS 2022-05-11 07:57:24 PDT

Test gardening commit r294052 (250458@main): <https://commits.webkit.org/250458@main>

Reviewed commits have been landed. Closing PR #588 and removing active labels.

Comment 10 Karl Rackler 2022-05-16 10:35:10 PDT

Marking the test as Slow has resulted in the tests passing consistently.

History: 
https://results.webkit.org/?suite=layout-tests&test=webaudio%2FAudioBuffer%2Fhuge-buffer.html&platform=ios&platform=mac&limit=50000

Comment 11 Karl Rackler 2022-05-17 09:21:44 PDT

Verified with Eric that the test can run slow and marking the test as slow has resolved the issue.