GNOME Bugzilla – Bug 758852
tsdemux segfault
Last modified: 2016-03-06 08:40:40 UTC
Testing random ideas, my setup was: * a client gstreamer getting a stream through UDP from netcat: nc -u -l -p 9999 | GST_DEBUG=WARN gst-launch-1.0 filesrc location=/dev/stdin ! \ tsdemux ! h264parse ! avdec_h264 ! glimagesink * a "server" gstreamer feeding the stream through UDP using netcat, using pv as rate-limiter GST_DEBUG=WARN gst-launch-1.0 filesrc location=~/Videos/big_buck_bunny_480p_h264.mov ! \ qtdemux ! h264parse ! mpegtsmux ! filesink location=/dev/stdout | pv -q -L 400k | nc -u localhost 9999 Quite rapidly the client side segfaults: Setting pipeline to PAUSED ... 0:00:00.045968933 3122 0x13f2c00 WARN basesrc gstbasesrc.c:3481:gst_base_src_start_complete:<filesrc0> pad not activated yet Pipeline is PREROLLING ... Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; 0:00:02.553049510 3122 0x13fb5e0 WARN libav gstavcodecmap.c:2419:gst_ffmpeg_caps_to_pixfmt: ignoring insane framerate 1/0 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock 0:00:05.030942214 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 2, stream 5 0:00:05.114448125 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 9, stream 12 0:00:05.322561262 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 4, stream 11 0:00:05.364483461 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 11, stream 14 0:00:05.447532807 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 3, stream 6 0:00:06.406019271 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 10, stream 12 0:00:06.490193888 3122 0x7f12b0021860 ERROR libav :0:: negative number of zero coeffs at 47 17 0:00:06.490256224 3122 0x7f12b0021860 ERROR libav :0:: error while decoding MB 47 17 0:00:06.530833728 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 4, stream 11 0:00:07.614250009 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 2, stream 14 0:00:07.905797932 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 2, stream 5 0:00:08.197616639 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 4, stream 7 0:00:08.197660427 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 12, stream 3 0:00:08.239524463 3122 0x13fb5e0 WARN tsdemux tsdemux.c:1910:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 4, stream 7 Caught SIGSEGV Segmentation fault (core dumped) and gdb seems to show that mpegts_packetizer_push_section has a wrong idea of the size of data it got. Safety check missing ? Potential for buffer overflow ? Core was generated by `gst-launch-1.0 filesrc location=/dev/stdin ! tsdemux ! h264parse ! avdec_h264 !'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 235775
Note that the segfault did not happen again after that first test.
I can see an assert on the receving side. Nor sure it's related, though, because: 0:00:01.848700092 29561 0x20c6540 ERROR GST_MEMORY gstmemory.c:324:gst_memory_map: mem 0x7f96a4231d40: subclass map failed Still something needing fixing.
Fixed by latest gst-libav, it errors out properly now, but there's a size mismatch in a map. I tracked this down to allocated memory being aligned, and thus decreasing the total size of the available area, but something somewhere uses the wrong size, and tries to access the whole of the buffer, rather than the "available after alignment" size. So there is definitely a memory bug here. If you use the latest git (including gst-libav), this should fix the crash, assuming we're seeing the same root cause. If it doesn't fix the crash, then we're seeing different issues.
Created attachment 320808 [details] [review] fix size mismatch when mapping realinged buffer I suppose I was too optimistic thinking this is the same issue, but you never know, might be secondary damage from memory corruption.
With this patch, your sample pipeline works here, albeit horrendously slowly.
Review of attachment 320808 [details] [review]: This doesn't seem right... ::: gst-libs/gst/gl/gstglbasememory.c @@ +200,3 @@ "pointer of size %" G_GSIZE_FORMAT, gl_mem, gl_mem->alloc_size); + maxsize = gl_mem->alloc_size + mem->align - 1; + gl_mem->alloc_data = g_try_malloc (maxsize); alloc_size is already maxsize + align. The fact that you're adding another + align is not correct. Also, align - 1 doesn't make any sense either. It would be useful to see some numbers as to why this is needed
I hadn't realized alloc_size was aleady resized to account for alignment. The align-1 was to account for it again. And indeed, not adding that alignment slack still works when one doesn't modify the object's maxsize (which doesn't need to as it can eat in that slack space).
Created attachment 320856 [details] [review] fix size mismatch when mapping realinged buffer
Ah, seems this was fixed already by bug 763045. I forgot that this patch existed. Sorry. *** This bug has been marked as a duplicate of bug 763045 ***