GNOME Bugzilla – Bug 334107
xviddec: segmentation fault after a few frames
Last modified: 2018-01-29 08:42:03 UTC
Steps to reproduce: 1. Start totem. 2. Play movie with xvid video codec. 3. Segmentaton fault occurs after a few frames. Stack trace:
+ Trace 66820
Other information: Using FC5-test3; and versions: gstreamer-plugins-bad-0.10.1-1.gst xvidcore-1.1.0-0.1.beta2.2.fc4.rf totem-1.3.92-1 File format: RIFF (little-endian) data, AVI, 624 x 352, 23.98 fps, video: XviD, audio: MPEG-1 Layer 3 (stereo, 48000 Hz)
can you make a sample video available somewhere?
Having recently done some development on the XviD plugins, I have also run across a share of segfaults (all within XviD). They are particularly likely to occur whenever both xviddec and xvidenc are part of the pipeline, strangely enough. Even stranger (?), adding efence can also make these disappear (though it is supposed to be provoke them :) ), so it seems inherently unstable in its occurence (depending on the memory layout ?) Anyway, to bring this babbling to something more concrete; on my system (using XviD 1.1.0 and latest GStreamer 0.10) the following is very likely to segfault: videotestsrc ! xvidenc ! efence ! xviddec ! xvimagesink (yes, *with* efence in this case :) ) Without efence, results come out just fine (so, elements seem to be telling xvid where to look?). Also no problems if the encoded material is placed in file (e.g. mkv) and then subsequently played. However, it does segfault upon playing when efence is inserted before xviddec.
I can reproduce the crash with videotestsrc ! xvidenc ! efence ! xviddec ! x(v)imagesink No idea where it's coming from though. I also noticed that xviddec seems to read over the input data passed to it - maybe it assumes the input is padded to 4/8/16 bytes or something? (easy to see when running gst-launch-0.10 ... ! avidemux ! xviddec ! xvimagesink on some .avi).
This one crashes after one frame (looks totally garbled when decoded with gst-ffmpeg, but at least doesn't crash). It may just be a corrupt file though: http://samples.mplayerhq.hu/V-codecs/XVID/
wild guess... it wouldn't be because the output buffer isn't 16-bytes aligned ? I can reproduce it in git -bad
Me too, when running it in valgrind nothing interesting is shown though.
Managed to get a stack trace building newest libxvidcore.
+ Trace 218452
Valgrind already moans with just: videotestsrc ! xvidenc ! fakesink Pipeline is PREROLLING ... ==32690== Thread 2: ==32690== Conditional jump or move depends on uninitialised value(s) ==32690== at 0xDA38978: idct_sse2_skal (in /home/v/lib/gstreamer-0.10/libgstxvid.so) ==32690== by 0xDA0DED3: MBTransQuantIntra (in /home/v/lib/gstreamer-0.10/libgstxvid.so) ==32690== by 0xDA149D2: FrameCodeI (in /home/v/lib/gstreamer-0.10/libgstxvid.so) ==32690== by 0xDA1625C: enc_encode (in /home/v/lib/gstreamer-0.10/libgstxvid.so) ==32690== by 0xD9DE49C: gst_xvidenc_encode (gstxvidenc.c:817) ==32690== by 0xD9DEF03: gst_xvidenc_chain (gstxvidenc.c:984) ==32690== by 0x4E84513: gst_pad_chain_data_unchecked (gstpad.c:4231) ==32690== by 0x4E84F46: gst_pad_push_data (gstpad.c:4463) ==32690== by 0x4E87FE8: gst_pad_push (gstpad.c:4685) ==32690== by 0xD145889: gst_base_src_loop (gstbasesrc.c:2503) ==32690== by 0x4EACDF4: gst_task_func (gsttask.c:318) ==32690== by 0x5F51460: ??? (in /usr/lib64/libglib-2.0.so.0.2600.1) ==32690==
That same valgrind report happens also with the sample encoder that comes with libxvidcore used on the supplied test video: valgrind ../../examples/xvid_encraw < CACTUS > FOO That is using xvidcore 1.3.0-rc1 (the latest available). Configuring xvidcore with --disable-assembly fixes it with xvid_encraw and the "videotestsrc ! xvidenc ! fakesink" pipeline. This does seem like a red herring though, since the original bug included only the decoder, but may explain why having xvidenc in the pipeline makes the trigger more likely.
So after some more looking around with only the decoder: The stock sample decoder from xvidcore does not trigger Valgrind problems, but gst's does. However, the sample decoder uses a very large read buffer (2 MB). If I reduce this buffer to the size of the next buffer, Valgrind starts moaning about the same issue. If I make a temporary copy of the incoming buffer in gst's xviddec.c, with 16 extra bytes added at the end, Valgrind's happy. An extra 4 bytes gets rid of some, but not all, triggers. So it looks like there is another overread in xvidcore. For the record, the sample decoder uses stock malloc, so alignment doesn't seem to be required.
*** Bug 585269 has been marked as a duplicate of this bug. ***
Created attachment 178018 [details] [review] xvid: bodge to avoid crashes It seems xvidcore overreads its input buffer, so a nasty workaround is to allocate some more memory (16 bytes seem to be enough). There is no apparent image corruption with these extra bytes set to 0, valgrind is much happier, and the crashes go away. It is ugly, and slower though.
commit c696b54fa72343e5f863a100b09adf54b3b912b4 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Tue Jan 11 10:32:47 2011 +0000 xviddec: bodge to avoid crashes It seems xvidcore overreads its input buffer, so a nasty workaround is to allocate some more memory (16 bytes seem to be enough). There is no apparent image corruption with these extra bytes set to 0, valgrind is much happier, and the crashes go away. It is ugly, and slower though. But then, xviddec is currently not autoplugged for playback anyway. https://bugzilla.gnome.org/show_bug.cgi?id=334107