Passing high playback rate crashes GStreamer.
Created attachment 223563 [details] Patch
Comment on attachment 223563 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=223563&action=review > LayoutTests/ChangeLog:3 > + [GStreamer] High playback rate causes crash Have you investigated that crash? Might be worth a GStreamer bug report. > LayoutTests/media/video-extreme-playbackrate-crash.html:15 > + video.playbackRate = 10000000; The spec (afaik) doesn't define the range of valid playbackRate values. So I don't think we should have a test for this, what do you think Eric? > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:866 > + // Higher rate causes crash. This is quite high indeed... I don't think these values make sense from a user point of view, limiting to (-10, 10) would perhaps be a more reasonable thing to do? And please use clampTo() from MathExtras.h
Program received signal SIGSEGV, Segmentation fault. 0x00007fe4292ed9ac in gst_structure_free (structure=0x7fe37000ba60) at gststructure.c:374 374 len = GST_STRUCTURE_FIELDS (structure)->len; (gdb) bt full #0 0x00007fe4292ed9ac in gst_structure_free (structure=0x7fe37000ba60) at gststructure.c:374 field = <optimized out> i = <optimized out> len = <optimized out> __PRETTY_FUNCTION__ = "gst_structure_free" #1 0x00007fe4292c2da3 in _gst_message_free (message=0x7fe39c0e26a0) at gstmessage.c:202 structure = 0x7fe37000ba60 __PRETTY_FUNCTION__ = "_gst_message_free" #2 0x00007fe4292a3c21 in gst_message_unref (msg=0x7fe39c0e26a0) at ../gst/gstmessage.h:336 No locals. #3 gst_bus_source_dispatch (source=source@entry=0x181bcc0, callback=<optimized out>, user_data=0x0) at gstbus.c:770 handler = <optimized out> bsource = 0x181bcc0 message = 0x7fe39c0e26a0 keep = 1 bus = 0x1633070 __PRETTY_FUNCTION__ = "gst_bus_source_dispatch" #4 0x00007fe428d392c5 in g_main_dispatch (context=0x12d3ab0) at gmain.c:3065 dispatch = 0x7fe4292a3b00 <gst_bus_source_dispatch> ---Type <return> to continue, or q <return> to quit--- was_in_call = 0 user_data = 0x0 callback = 0x7fe4292a2f80 <gst_bus_async_signal_func> cb_funcs = 0x7fe4290179e0 cb_data = 0x19f0550 current_source_link = {data = 0x181bcc0, next = 0x0} need_destroy = <optimized out> source = 0x181bcc0 current = 0x15abec0 i = <optimized out> #5 g_main_context_dispatch (context=context@entry=0x12d3ab0) at gmain.c:3641 No locals. #6 0x00007fe428d39608 in g_main_context_iterate (context=0x12d3ab0, block=block@entry=1, dispatch=dispatch@entry=1, self=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at gmain.c:3712 max_priority = 120 timeout = 0 some_ready = 1 allocated_nfds = <optimized out> fds = 0x1868080 nfds = <optimized out> #7 0x00007fe428d39a6a in g_main_loop_run (loop=0x1614d60) at gmain.c:3906 ---Type <return> to continue, or q <return> to quit--- __PRETTY_FUNCTION__ = "g_main_loop_run" #8 0x00007fe429d18045 in gtk_main () at gtkmain.c:1162 loop = 0x1614d60 #9 0x00000000004059e8 in main (argc=1, argv=0x7fff64101f78) at ../../Tools/GtkLauncher/main.c:561 webkitSettings = 0x1335c80 uriArguments = 0x0 commandLineOptions = {{long_name = 0x405ef4 "", short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_FILENAME_ARRAY, arg_data = 0x7fff64101de0, description = 0x0, arg_description = 0x405ef5 "[URL]"}, {long_name = 0x0, short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x0, description = 0x0, arg_description = 0x0}} context = 0x131a200 error = 0x0 webView = 0x14c6290 main_window = 0x14b5150 uri = 0x405f2f "http://www.google.com/" fileURL = 0x0 stack trace after going from google to layout test.
Created attachment 223687 [details] Patch
Comment on attachment 223563 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=223563&action=review >> LayoutTests/media/video-extreme-playbackrate-crash.html:15 >> + video.playbackRate = 10000000; > > The spec (afaik) doesn't define the range of valid playbackRate values. So I don't think we should have a test for this, what do you think Eric? The spec doesn't define a limit, but Piotr is fixing a bug so I think the test is fine.
Comment on attachment 223687 [details] Patch Clearing flags on attachment: 223687 Committed r163871: <http://trac.webkit.org/changeset/163871>
All reviewed patches have been landed. Closing bug.