Since enabling fatal criticals for layout tests, many media source tests are now crashing with the following error in gst_qtdemux_configure_stream(): GStreamer-CRITICAL **: _gst_util_uint64_scale: assertion 'denom != 0' failed I'm adding crash expectations for the following tests: imported/w3c/web-platform-tests/media-source/mediasource-append-buffer.html imported/w3c/web-platform-tests/media-source/mediasource-appendwindow.html imported/w3c/web-platform-tests/media-source/mediasource-detach.html imported/w3c/web-platform-tests/media-source/mediasource-duration.html imported/w3c/web-platform-tests/media-source/mediasource-getvideoplaybackquality.html imported/w3c/web-platform-tests/media-source/mediasource-play-then-seek-back.html imported/w3c/web-platform-tests/media-source/mediasource-play.html imported/w3c/web-platform-tests/media-source/mediasource-redundant-seek.html imported/w3c/web-platform-tests/media-source/mediasource-remove.html imported/w3c/web-platform-tests/media-source/mediasource-seek-beyond-duration.html imported/w3c/web-platform-tests/media-source/mediasource-seek-during-pending-seek.html imported/w3c/web-platform-tests/media-source/mediasource-sourcebuffer-mode.html Sample backtrace: Thread 1 (Thread 0x7fd8fbfff700 (LWP 10626)): #0 _g_log_abort () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gmessages.c:549 #1 0x00007fda1fc1a1b5 in g_logv () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gmessages.c:1357 #2 0x00007fda1fc1a302 in g_log () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gmessages.c:1398 #3 0x00007fda20c994c0 in _gst_util_uint64_scale () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstutils.c:479 #4 0x00007fd9b969e452 in gst_qtdemux_configure_stream () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gst-plugins-good-1.10.5/gst/isomp4/qtdemux.c:7747 #5 0x00007fd9b96b9e8b in gst_qtdemux_process_adapter () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gst-plugins-good-1.10.5/gst/isomp4/qtdemux.c:6730 #6 0x00007fda20c5d8f7 in gst_pad_chain_data_unchecked () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4202 #7 gst_pad_push_data () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4454 #8 0x00007fda20c658f2 in gst_pad_push () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4573 #9 0x00007fda20d50895 in gst_base_src_loop () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/libs/gst/base/gstbasesrc.c:2854 #10 0x00007fda20c90981 in gst_task_func () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gsttask.c:334 #11 0x00007fda1fc3acee in g_thread_pool_thread_proxy () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gthreadpool.c:307 #12 0x00007fda1fc3a315 in g_thread_proxy () at /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gthread.c:784 #13 0x00007fda1ca52494 in start_thread (arg=0x7fd8fbfff700) at pthread_create.c:333 #14 0x00007fda1b8b793f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Has this started appearing on the bots just recently? The issue has been there for long when I ran the tests in my computer.
No, it's been happening for ages. But I changed criticals to be fatal yesterday to reflect the severity of these bugs, so only now are the tests crashing.
By the way, half these tests were already failing anyway. The test expectations are starting to become a bit messy as I've now filed a second bug report for many multimedia tests that previously had only failure bug reports and now have a second crash bug report as well. That started a couple weeks ago, not just yesterday. Really not pleased about the state of our multimedia tests. :(
Created attachment 321561 [details] Patch
It seems a Gstreamer bug. Uploaded patch should fix the issue. wdyt?
It's fine by me as long as the patch is submitted upstream. Enrique, can you review it please?
Comment on attachment 321561 [details] Patch Attachment 321561 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/4630156 New failing tests: fast/canvas/webgl/texImage2D-video-flipY-true.html
Created attachment 321586 [details] Archive of layout-test-results from ews124 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.6
This is being tracked in GStreamer bugzilla here: https://bugzilla.gnome.org/show_bug.cgi?id=782217 The patch looks good to me, but could you please submit the original gst-plugins-good patch to the bug above?
The patch has been approved upstream. In the meanwhile until the next stable version is released we should commit the patch internally for our jhbuild so we stop getting stderr in our test runs. You may want to consider this upstream commit from Sebastian when doing so: https://github.com/GStreamer/gst-plugins-good/commit/728a1629cf9fd7f4a728477bda1d13a1ecc219bb
Created attachment 323414 [details] Patch
Thanks for the reviews.
Comment on attachment 323414 [details] Patch Clearing flags on attachment: 323414 Committed r223178: <https://trac.webkit.org/changeset/223178>
All reviewed patches have been landed. Closing bug.
<rdar://problem/34933168>
Comment on attachment 323414 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323414&action=review > Tools/gstreamer/jhbuild.modules:81 > + <patch file="gst-plugins-good-0009-qtdemux-fix-assert-when-moof-contains-one-sample.patch" strip="1"/> Is this patch already upstream? in which version is (or will be) released? Please, when adding patches to jhbuild, add a comment line before the patch replying this question and documenting what the patch does and why it's needed. Otherwise, when bumping the gst version we don't know if we still need this patch or not.
> Is this patch already upstream? in which version is (or will be) released? Yes, it is fixed upstream. GStreamer bug report [1] indicates that the target milestone is version 1.13.1. > Please, when adding patches to jhbuild, add a comment line before the patch > replying this question and documenting what the patch does and why it's > needed. Otherwise, when bumping the gst version we don't know if we still > need this patch or not. I will upload a new patch to document why this gstreamer patch is required. [1] https://bugzilla.gnome.org/show_bug.cgi?id=782217