Bug 225670 - [ BigSur ] webaudio/AudioContext/audiocontext-close-basic.html (layout-test) is a flaky timeout
Summary: [ BigSur ] webaudio/AudioContext/audiocontext-close-basic.html (layout-test) ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-05-11 12:02 PDT by Robert Jenner
Modified: 2021-05-13 10:52 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Jenner 2021-05-11 12:02:16 PDT
webaudio/AudioContext/audiocontext-close-basic.html

is a flaky timeout on BigSur. 

HISTORY:
https://results.webkit.org/?suite=layout-tests&test=webaudio%2FAudioContext%2Faudiocontext-close-basic.html

TIMEOUT TEXT:
Wait on notifyDone timed out, process WebKitTestRunner pid = 53481#EOF


STDERR TEXT:
2021-05-11 09:47:39.764 DumpRenderTree[17988:145650319] nil host used in call to allowsSpecificHTTPSCertificateForHost
2021-05-11 09:47:39.764 DumpRenderTree[17988:145650319] nil host used in call to allowsAnyHTTPSCertificateForHost:

The STDERR was from a wk1 Debug run.
Comment 1 Robert Jenner 2021-05-11 14:58:20 PDT
Flaky timeouts first started to occur at r276186. Before that the test was passing consistently. 

Working on reproduction steps.
Comment 2 Radar WebKit Bug Importer 2021-05-11 14:58:59 PDT
<rdar://problem/77866215>
Comment 3 Alexey Proskuryakov 2021-05-11 16:33:09 PDT
Given this text, it was presumably the first test in a shard. Not that it's a reason for timing out.
Comment 4 Chris Dumez 2021-05-12 09:59:40 PDT
I think the test is just slow because it is working with many AudioContexts. If you look at the flakiness dashboard, you can see that the test is sometimes passing with high run times (e.g. 22 seconds) so it is not too surprising if it can reach the 30 seconds timeout.
Comment 5 Chris Dumez 2021-05-12 10:18:14 PDT
Test takes 6-8 seconds to run on my machine (which is powerful). I'll see if we can either make the test or our implementation faster.
Comment 6 Robert Jenner 2021-05-12 16:02:48 PDT
Updated test expectations to [ Slow ] to see if flaky timeouts stop here:
https://trac.webkit.org/changeset/277403/webkit
Comment 7 Chris Dumez 2021-05-13 10:34:10 PDT
(In reply to Robert Jenner from comment #6)
> Updated test expectations to [ Slow ] to see if flaky timeouts stop here:
> https://trac.webkit.org/changeset/277403/webkit

Notice the lack of timeouts since the test was marked slow. We have test runs that take 35-38 seconds on some of the bots.
Comment 8 Robert Jenner 2021-05-13 10:52:46 PDT
(In reply to Chris Dumez from comment #7)
> (In reply to Robert Jenner from comment #6)
> > Updated test expectations to [ Slow ] to see if flaky timeouts stop here:
> > https://trac.webkit.org/changeset/277403/webkit
> 
> Notice the lack of timeouts since the test was marked slow. We have test
> runs that take 35-38 seconds on some of the bots.

Absolutely! I suppose this is a good thing, and means that now this is just a performance issue now? In any case, I'm glad it's not timing out anymore.