GNOME Bugzilla – Bug 762148
dashdemux: correctly handle an HTTP-XSDATE that is exactly the size of the date string
Last modified: 2016-04-14 17:43:00 UTC
The code in the gst_dash_demux_parse_http_xsdate() was trying to handle the case where the string is not null terminated by resizing the buffer and appending a zero byte. This does not work if the buffer is exactly the length of the string because the gst_buffer_resize() function does not re-allocate the buffer, it just changes its size. If a buffer is passed to gst_dash_demux_parse_http_xsdate() that is exactly the length of the string, the function fails with an assert failure in gst_buffer_resize().
Created attachment 321396 [details] [review] proposed patch
Comment on attachment 321396 [details] [review] proposed patch Thanks, looks good, just a few small comments: >+ gpointer str; gchar *str; >+ str = g_malloc0 (gst_buffer_get_size (buffer) + 1); >+ if (gst_buffer_map (buffer, &mapinfo, GST_MAP_READ)) { >+ memcpy (str, mapinfo.data, gst_buffer_get_size (buffer)); Could just do str = g_strndup (mapinfo.data, mapinfo.size); here which will add a 0-terminator for you.
Comment on attachment 321396 [details] [review] proposed patch Florin, can you update the patch?
Created attachment 321935 [details] [review] proposed patch
commit 72e46a447818a484e24caeecd33915612e4b0be8 Author: Florin Apostol <florin.apostol@oregan.net> Date: Tue Feb 23 10:49:40 2016 +0000 dashdemux: correctly handle an HTTP-XSDATE that is exactly the size of the date string The code in the gst_dash_demux_parse_http_xsdate() was trying to handle the case where the string is not null terminated by resizing the buffer and appending a zero byte. This does not work if the buffer is exactly the length of the string because the gst_buffer_resize() function does not re-allocate the buffer, it just changes its size. If a buffer is passed to gst_dash_demux_parse_http_xsdate() that is exactly the length of the string, the function fails with an assert failure in gst_buffer_resize(). https://bugzilla.gnome.org/show_bug.cgi?id=762148