Bug 83878 – Flaky media/track/track-mode test

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Philippe Normand]

Reported flaky on 64-bit Release and Debug bots. Diff:

--- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-mode-expected.txt 
+++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-mode-actual.txt 
@@ -1,3 +1,4 @@
+FAIL: Timed out waiting for notifyDone to be called
 Tests that the TextTrack mode attribute is appropriately set.
 
 
@@ -38,7 +39,4 @@
 EXPECTED (textTrack.activeCues.length == '1') OK
 EVENT(cuechange)
 EXPECTED (textTrack.activeCues.length == '1') OK
-EVENT(cuechange)
-EXPECTED (textTrack.activeCues.length == '1') OK
-END OF TEST
 
Will flag it accordingly.

[Zan Dobersek]

The test changes originate from bug #83377.
Committed in http://trac.webkit.org/changeset/114026, before that the test seemed to have run successfully.

[Philippe Normand]

CCing Anna about this test failure :)

[Zan Dobersek]

Also observed by the Chromium port:
https://bugs.webkit.org/show_bug.cgi?id=83882

I think this can be resolved as a duplicate.

[Philippe Normand]

*** Bug 83882 has been marked as a duplicate of this bug. ***

[Anna Cavender]

Thanks for reporting.

I think this patch should fix the flakiness:
https://bugs.webkit.org/show_bug.cgi?id=83858

[Alexey Proskuryakov]

Marking as duplicate per Anna's comment. Please re-open if still flaky.

*** This bug has been marked as a duplicate of bug 83858 ***

[Anna Cavender]

Looks like this test is still flaky:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&showExpectations=true&revision=114250&tests=media%2Ftrack%2Ftrack-mode

I think it's just that the cue timings are a bit too close together and aren't fired predictably.  Patch coming to space them out and we'll see if that fixes the problem.

[Anna Cavender]

Created attachment 137378 [details]
Patch

[Eric Carlson]

Comment on attachment 137378 [details]
Patch

I am not convinced that this will fix the issue on a slow or heavily loaded system, but it is worth a try (and I don't have a better idea at the moment).

[Anna Cavender]

Thanks Eric, I'll give it a try.

[WebKit Review Bot]

Comment on attachment 137378 [details]
Patch

Clearing flags on attachment: 137378

Committed r114650: <http://trac.webkit.org/changeset/114650>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Anna Cavender]

*** Bug 83882 has been marked as a duplicate of this bug. ***

[Anna Cavender]

Nope, definitely not fixed yet.

[Gyuyoung Kim]

When I test media/track/track-mode.html on EFL layout test, this test case comes to crash.

I'm not sure whether this crash's able to be covered by this bug. Fortunately, this test was added to EFL's test_expectations.txt


Backtrace is as below,

(gdb) bt
#0  0x0832a85e in WebCoreTestSupport::injectInternalsObject(OpaqueJSContext const*) ()
#1  0x08077590 in DumpRenderTreeChrome::onWindowObjectCleared(void*, _Evas_Object*, void*) ()
#2  0xb62f2b5c in evas_object_smart_callback_call (obj=0xb268e038, event=0xb7b98499 "window,object,cleared", event_info=0xbfffe440) at evas_object_smart.c:460
#3  0xb670aec8 in WebCore::FrameLoaderClientEfl::dispatchDidClearWindowObjectInWorld(WebCore::DOMWrapperWorld*) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#4  0xb6a07d4b in WebCore::FrameLoader::dispatchDidClearWindowObjectInWorld(WebCore::DOMWrapperWorld*) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#5  0xb6eb3c31 in WebCore::ScriptController::initScript(WebCore::DOMWrapperWorld*) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#6  0xb6eb42fc in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#7  0xb6eb470b in WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#8  0xb73018ba in WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#9  0xb695556d in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript&) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#10 0xb69561ec in WebCore::HTMLScriptRunner::executeParsingBlockingScripts() () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#11 0xb694f662 in WebCore::HTMLDocumentParser::notifyFinished(WebCore::CachedResource*) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#12 0xb6a65323 in WebCore::CachedResource::checkNotify() [clone .part.178] () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#13 0xb6a723bc in WebCore::CachedScript::data(WTF::PassRefPtr<WebCore::SharedBuffer>, bool) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#14 0xb6a46129 in WebCore::SubresourceLoader::didFinishLoading(double) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#15 0xb6a3db27 in WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#16 0xb71d8cc6 in WebCore::readCallback(_GObject*, _GAsyncResult*, void*) () from /home/gyuyoung/webkit/WebKit/WebKitBuild/Release/lib/libewebkit.so.0
#17 0xb5cf83c1 in async_ready_callback_wrapper (source_object=0x994aef0, res=0x9a07930, user_data=0xb33fa520) at ginputstream.c:470
#18 0xb5d0ca85 in g_simple_async_result_complete (simple=0x9a07930) at gsimpleasyncresult.c:767
#19 0xb5d0cb03 in complete_in_idle_cb_for_thread (_data=0x9a032e0) at gsimpleasyncresult.c:835
#20 0xb5ef56e0 in g_idle_dispatch (source=0xb1004ff8, callback=0xb5d0cad0 <complete_in_idle_cb_for_thread>, user_data=0x9a032e0) at gmain.c:4657
#21 0xb5ef7c16 in g_main_dispatch (context=0x9a08378) at gmain.c:2539
#22 g_main_context_dispatch (context=0x9a08378) at gmain.c:3075
#23 0xb6294965 in _ecore_glib_select__locked (ecore_timeout=0xbfffedc8, efds=0xbfffed48, wfds=0xbfffecc8, rfds=0xbfffec48, ecore_fds=11, ctx=0x9a08378) at ecore_glib.c:171
#24 _ecore_glib_select (ecore_fds=11, rfds=0xbfffec48, wfds=0xbfffecc8, efds=0xbfffed48, ecore_timeout=0xbfffedc8) at ecore_glib.c:205
#25 0xb628e46f in _ecore_main_select (timeout=0) at ecore_main.c:1419
#26 0xb628ef57 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1835
#27 0xb628f2f7 in ecore_main_loop_begin () at ecore_main.c:906
#28 0x08076858 in runTest(char const*) ()
#29 0x0806a590 in main ()

[Kangil Han]

It seems complicated.
I reproduced only once in 30-50 times on my EFL layout test.

[Anna Cavender]

I believe this test is timing out for slow or bogged down systems because cuechange events are fired asynchronously, and could potentially fire out of order.  This test checks the contents of the cues, which is unnecessary.  Let's change it to just test that the cuechange events are firing when TextTrack.mode is HIDDEN or SHOWING, and not depend on the order of those events.

[Anna Cavender]

Created attachment 158597 [details]
remove requirement that cuechange events fire in order

[Eric Seidel (no email)]

Comment on attachment 158597 [details]
remove requirement that cuechange events fire in order

OK.

[WebKit Review Bot]

Comment on attachment 158597 [details]
remove requirement that cuechange events fire in order

Clearing flags on attachment: 158597

Committed r126364: <http://trac.webkit.org/changeset/126364>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Jussi Kukkonen (jku)]

I'm reopening this on and not filing a new bug as GTK TestExpectations still links here.

media/track/track-mode.html is flaky on at least EFL, GTK and Apple Mountainlion. It looks like a timing problem as normal runs take 1-3 seconds but a failing test fails at 30secs. 

Interestingly on GTK there's a timeout at 6secs (or 12sec on debug). Does GTK do something different here?

I'm not able to reproduce this on EFL with --iterations and have been unable to find another test that would trigger this.

[Eric Carlson]

r149197 (https://bugs.webkit.org/show_bug.cgi?id=115045) may have fixed this.

[Diego Pino]

This test was only filed as a failure in GLIB ports:

media/track/track-mode.html [ Timeout Pass ]

The test has been constantly passing for the last 1000 revisions:

https://results.webkit.org/?limit=1000&platform=GTK&platform=WPE&suite=layout-tests&test=media%2Ftrack%2Ftrack-mode.html

Marking the bug as resolved.

Test removed from test expectations in r287490.