GNOME Bugzilla – Bug 342097
[jpegdec] crash with attached JPEG file
Last modified: 2006-05-22 15:31:46 UTC
Steps to reproduce: $ gst-launch -v playbin uri=file:///home/sam/cover.jpg Setting pipeline to PAUSED ... /playbin0/decoder.sink: caps = NULL /playbin0/decoder/typefind.src: caps = image/jpeg /playbin0/decoder.src0: caps = NULL /playbin0/selector_video_src0: active-pad = "sink0" /playbin0/vbin.sink: caps = NULL Pipeline is PREROLLING ... /playbin0/decoder/jpegdec0.sink: caps = image/jpeg /playbin0/decoder/jpegdec0.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/id.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/id.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/preroll_video_src0.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/selector_video_src0.sink0: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/decoder.src0: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/decoder.src0.proxypad1: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/selector_video_src0.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/preroll_video_src0.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/vconv.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/vconv.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/vscale.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/vscale.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/videosink/actual-sink.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 /playbin0/vbin/videosink.sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)200, height=(int)200, framerate=(fraction)0/1 *** glibc detected *** corrupted double-linked list: 0x0825e808 *** Aborted Stack trace: For some reason I can't get one: (gdb) run Starting program: /usr/bin/gst-launch playbin 'uri=file:///home/sam/cover.jpg' (no debugging symbols found) Setting pipeline to PAUSED ... Program received signal SIG32, Real-time event 32. Program received signal SIG32, Real-time event 32. Program received signal SIG32, Real-time event 32. Pipeline is PREROLLING ... Program received signal SIG32, Real-time event 32. Program received signal SIG32, Real-time event 32. Program received signal SIG32, Real-time event 32. Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) where No stack. Other information:
Created attachment 65651 [details] cover.jpg
Created attachment 65691 [details] [review] fix This fix is ... umm, well, it makes things works. We probably can tell jpeglib to do all this for us somehow, but I have absolutely no idea how.
Committed: 2006-05-22 Tim-Philipp Müller <tim at centricular dot net> * ext/jpeg/gstjpegdec.c: (hresamplecpy1), (gst_jpeg_dec_decode_indirect), (gst_jpeg_dec_chain): Fix crashes when the horizontal subsampling is 1. Fixes #342097. Ideally we should probably just be pushing buffers in the source format, so that we don't need to do adjustments like this, however: - we still need fallback code for the case where we don't have a matching format (e.g. r_v != r_h) - more formats = more codepaths and more complexity = higher chance of gettings things wrong (like offsets/strides etc.) - in this particular case (r_v=1, r_h=1) the only matching YUV format we have seems to be AYUV, so we'd be push a bogus alpha plane and a format that most likely requires a colorspace conversion somewhere downstream anyway. That doesn't exactly seem worth the extra trouble.