Bug 128453 - [GStreamer] High playback rate causes crash
Summary: [GStreamer] High playback rate causes crash
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-08 04:22 PST by Piotr Grad
Modified: 2014-02-11 02:04 PST (History)
11 users (show)

See Also:


Attachments
Patch (3.61 KB, patch)
2014-02-08 04:24 PST, Piotr Grad
pnormand: review-
pnormand: commit-queue-
Details | Formatted Diff | Diff
Patch (3.51 KB, patch)
2014-02-10 02:39 PST, Piotr Grad
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Grad 2014-02-08 04:22:27 PST
Passing high playback rate crashes GStreamer.
Comment 1 Piotr Grad 2014-02-08 04:24:44 PST
Created attachment 223563 [details]
Patch
Comment 2 Philippe Normand 2014-02-09 20:41:03 PST
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
Comment 3 Piotr Grad 2014-02-10 01:22:32 PST
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.
Comment 4 Piotr Grad 2014-02-10 02:39:29 PST
Created attachment 223687 [details]
Patch
Comment 5 Eric Carlson 2014-02-10 07:40:46 PST
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 6 WebKit Commit Bot 2014-02-11 02:04:21 PST
Comment on attachment 223687 [details]
Patch

Clearing flags on attachment: 223687

Committed r163871: <http://trac.webkit.org/changeset/163871>
Comment 7 WebKit Commit Bot 2014-02-11 02:04:26 PST
All reviewed patches have been landed.  Closing bug.