GNOME Bugzilla – Bug 690701
mpeg2dec: Segfault on aspect change in dvb/multicast stream
Last modified: 2013-07-17 18:39:23 UTC
Created attachment 232206 [details] Backtrace By receiving end of program (or start of new program) my player mostly fails with sigsegv. Backtrack attached. Not simple to reproduce, because I have to wait for end of a program. I am not sure, if this is a gstreamer or libmpeg problem. I use playbin to play dvb and other streams using python gi interface.
clarification: This happens on change of aspect ratio (from 4:3 to 16;9) in stream. Does not matter, if source is from dvb or multicast.
Even if this is not 100% reproducible (not sure, when it happens, but aprox. 70%), If you can provide me an patch, I can retest it.
Could you capture a sample stream and make it available somewhere? I've tried with the clip from bug #591919, and it works just fine for me.
OK, here it is: http://work.salstar.sk/public/140044.ts Here is command, which throws core dump: gst-launch-1.0 playbin uri=file://`pwd`/140044.ts and it's error message: Caught SIGSEGV accessing address 0xad9be060
+ Trace 231326
Thanks a lot, I can reproduce the problem with this sample.
==16778== Thread 2: ==16778== Invalid read of size 8 ==16778== at 0x9D94258: ??? (in /usr/lib/x86_64-linux-gnu/libmpeg2.so.0.1.0) ==16778== by 0x9D8C8D4: ??? (in /usr/lib/x86_64-linux-gnu/libmpeg2.so.0.1.0) ==16778== by 0x9D8F12B: mpeg2_slice (in /usr/lib/x86_64-linux-gnu/libmpeg2.so.0.1.0) ==16778== by 0x9D84897: mpeg2_parse (in /usr/lib/x86_64-linux-gnu/libmpeg2.so.0.1.0) ==16778== by 0x9B7C195: gst_mpeg2dec_handle_frame (gstmpeg2dec.c:972) ==16778== by 0x94885E3: gst_video_decoder_decode_frame (gstvideodecoder.c:2666) ==16778== by 0x948C8FA: gst_video_decoder_chain_forward (gstvideodecoder.c:1698) ==16778== by 0x948DA40: gst_video_decoder_chain (gstvideodecoder.c:1958) ==16778== by 0x4E92839: gst_pad_push_data (gstpad.c:3654) ==16778== by 0x8553FC6: gst_base_parse_push_frame (gstbaseparse.c:2146) ==16778== by 0x8557AB2: gst_base_parse_finish_frame (gstbaseparse.c:1968) ==16778== by 0x8E130A1: gst_mpegv_parse_handle_frame (gstmpegvideoparse.c:619) ==16778== Address 0xb665d70 is 144 bytes inside a block of size 622,239 free'd ==16778== at 0x4C28F5C: free (vg_replace_malloc.c:446) ==16778== by 0x4E66BB0: _gst_buffer_free (gstmemory.h:299) ==16778== by 0x4E6A862: default_stop (gstbufferpool.c:382) ==16778== by 0x4E6A536: do_stop (gstbufferpool.c:402) ==16778== by 0x4E6A8C7: dec_outstanding.part.0 (gstbufferpool.c:1037) ==16778== by 0x4E6C249: gst_buffer_pool_release_buffer (gstbufferpool.c:1031) ==16778== by 0x4E66D42: _gst_buffer_dispose (gstbuffer.c:493) ==16778== by 0x4E8E4B5: gst_mini_object_unref (gstminiobject.c:448) ==16778== by 0x855C90A: gst_base_sink_set_last_buffer_unlocked (gstbuffer.h:350) ==16778== by 0x855CA1D: gst_base_sink_set_last_buffer (gstbasesink.c:967) ==16778== by 0x8563D7A: gst_base_sink_chain_unlocked.isra.11 (gstbasesink.c:3333) ==16778== by 0x8564E4B: gst_base_sink_chain_main (gstbasesink.c:3447) ==16778==
Does this still happen with git master ?
Still happens with 1.0.7, but not so often. I can't test git master now. Can you point me to any patch, which I can apply to current stable branch and retest?
Thanks for the reply. The easiest would be to make that sample available again (it's giving me a 404 right now).
Tim has a copy of it. Tim, please, can you send it to Edward.
No reason really why anything should've changed since I tested and confirmed this the last time.. http://people.freedesktop.org/~tpm/samples/690701-140044-aspect-ratio-change-crash.ts
To avoid any doubt, yes I re-tested and it is still an issue with git master.
commit 576fe462bc51a2d2f71236cf95777be061ee2fae Author: Edward Hervey <edward@collabora.com> Date: Wed Jul 17 16:17:54 2013 +0200 mpeg2dec: Properly reset on sequence changes Otherwise we end up using stray data/buffers. Fixes #690701
Yay, cherry-picked into 1.0 branch. Thanks for fixing this!