[Bug 770019] New: spltmuxsink crashes on 32-bit platform

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770019

            Bug ID: 770019
           Summary: spltmuxsink  crashes on 32-bit platform
    Classification: Platform
           Product: GStreamer
           Version: 1.8.2
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: yangtzj at hotmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 333444
  --> https://bugzilla.gnome.org/attachment.cgi?id=333444&action=edit
Patch to fix splitmuxsink crash on 32-bit platform

On 32-bit platform, Splitmuxsink will crash when the total amount of data
approximate 4G bytes.
And it can be reproduced by running the following pipeline on 32-bit platform.

gst-launch-1.0  -v videotestsrc is-live=1 !
'video/x-raw,format=I420,width=1280,height=720,framerate=25/1' ! x264enc
bitrate=102400 ! h264parse ! splitmuxsink max-size-time=10000000000
location=video%05d.mp4


When the pipeline crashes, the following msg is output:
"
ERROR:gstsplitmuxsink.c:852:handle_gathered_gop: assertion failed:
(queued_bytes >= splitmux->mux_start_bytes)
"


The potential reason is that some variables(such as structure
MqStreamCtx.in_bytes, struct  _GstSplitMuxSink.muxed_out_bytes) used (in
gstsplitmuxsink.c) to count the bytes number is of type gsize.
And on 32-bit platforms, gsize is 4-bytes wide. These variables will overrun as
time goes by.

For example, inside function handle_mq_input() in gstsplitmuxsink.c, 
at line 1125:

ctx->in_bytes += buf_info->buf_size;

ctx->in_bytes is continually increased by 'buf_size' every time a buf is
received. Sooner or later, ctx->in_bytes will overrun and cause crashes.


The fix is quite straightforward.
Just replace some 'gsize' type by 'guint64' type, as described in the enclosed
attachment.
And the fix has been tested and works well.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.