Bug 170188 - [mac-wk1 debug] LayoutTest media/track/track-cue-rendering-with-padding.html is a flaky timeout
Summary: [mac-wk1 debug] LayoutTest media/track/track-cue-rendering-with-padding.html ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Per Arne Vollan
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-28 11:08 PDT by Ryan Haddad
Modified: 2017-03-30 23:54 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.48 KB, patch)
2017-03-29 23:51 PDT, Per Arne Vollan
eric.carlson: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Alexey Proskuryakov 2017-03-29 09:47:02 PDT
No timeouts from 2017-3-5 till 2017-3-16; one on 2017-3-16; frequent timeouts starting 2017-3-27.
Comment 2 Per Arne Vollan 2017-03-29 23:51:32 PDT
Created attachment 305841 [details]
Patch
Comment 3 Eric Carlson 2017-03-30 08:52:04 PDT
Comment on attachment 305841 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=305841&action=review

> LayoutTests/media/track/track-cue-rendering-with-padding.html:20
> +        var maxRetries = 256;

This means the test won't fail for 25 seconds. What made you choose such a long time, it seems *extremely* unlikely that it could take that long for the cue display element to be created.
Comment 4 Per Arne Vollan 2017-03-30 09:35:10 PDT
(In reply to Eric Carlson from comment #3)
> Comment on attachment 305841 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=305841&action=review
> 
> > LayoutTests/media/track/track-cue-rendering-with-padding.html:20
> > +        var maxRetries = 256;
> 
> This means the test won't fail for 25 seconds. What made you choose such a
> long time, it seems *extremely* unlikely that it could take that long for
> the cue display element to be created.

I chose a long time in order to make sure that if the test fails again, it was definitely not because we picked a too short time. But 25 seconds is probably a little too long, though :)
Comment 5 Per Arne Vollan 2017-03-30 09:35:49 PDT
Comment on attachment 305841 [details]
Patch

Thanks for reviewing!
Comment 6 Alexey Proskuryakov 2017-03-30 09:53:26 PDT
FWIW, 20 to 25 seconds is what I'd have picked too. The delays can be huge sometimes (think of 18 media tests running with GuardMalloc in parallel, and a couple of them crashing).
Comment 7 WebKit Commit Bot 2017-03-30 13:38:19 PDT
Comment on attachment 305841 [details]
Patch

Rejecting attachment 305841 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'apply-attachment', '--no-update', '--non-interactive', 305841, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:

Parsed 2 diffs from patch file(s).
patching file LayoutTests/ChangeLog
Hunk #1 succeeded at 1 with fuzz 3.
patching file LayoutTests/media/track/track-cue-rendering-with-padding.html
Hunk #1 FAILED at 16.
Hunk #2 FAILED at 26.
2 out of 2 hunks FAILED -- saving rejects to file LayoutTests/media/track/track-cue-rendering-with-padding.html.rej

Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Eric Carlson']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Full output: http://webkit-queues.webkit.org/results/3442599
Comment 8 Per Arne Vollan 2017-03-30 23:54:25 PDT
Committed <https://trac.webkit.org/changeset/214612/webkit>.