GNOME Bugzilla – Bug 597351
[jpegdec] segfaults on a specific picture
Last modified: 2009-10-13 00:12:50 UTC
Created attachment 144739 [details] picture that makes the extractor segfault As described partly on bug 597276, rygel segfaults on its initial indexing on one of my file (attached). This is using 4.0.1 on a karmic install (using James Henstridge's PPA).
Can reproduce it, forwarding it to GStreamer
+ Trace 218059
Thread 2976168816 (LWP 5321)
I can confirm it too and I am looking into it right now. valgrind complains about unint uninitialized memory. ==22715== Use of uninitialised value of size 4 ==22715== at 0x48E7838: (within /usr/lib/libjpeg.so.62.1.0) ==22715== by 0x67C255F: ??? ==22715== by 0x48DE881: decompress_onepass (jdcoefct.c:240) ==22715== by 0x48D6E1E: jpeg_read_raw_data (jdapistd.c:210) ==22715== by 0x4033566: gst_jpeg_dec_chain (gstjpegdec.c:768) ==22715== by 0x40AA026: gst_pad_chain_data_unchecked (gstpad.c:4045) ==22715== by 0x40AAC58: gst_pad_push_data (gstpad.c:4274) ==22715== by 0x488007F: gst_base_src_loop (gstbasesrc.c:2323) ==22715== by 0x40CF5D2: gst_task_func (gsttask.c:234) ==22715== by 0x40D0F56: default_func (gsttaskpool.c:70) ==22715== by 0x41EAE25: g_thread_pool_thread_proxy (gthreadpool.c:265) ==22715== by 0x41E97BE: g_thread_create_proxy (gthread.c:635) ==22715== by 0x42514FE: start_thread (pthread_create.c:297) ==22715== by 0x434849D: clone (clone.S:130) Caught SIGSEGV accessing address 0x41e94e4 I have decoded the image using djpeg (comes with libjpeg and there it works).
There are different quantisation modes for jpeg color components. The first two have been made using gime and stored with the different quantisation, the last one is the attached one and its quantisation is not supported by gimp. gst-launch filesrc location=test_1152_864_22_11_11.jpeg ! jpegdec ! fakesink r_h = 2, r_v = 2 num_components=3, comps_in_scan=3 [0] h_samp_factor=2, v_samp_factor=2 [1] h_samp_factor=1, v_samp_factor=1 [2] h_samp_factor=1, v_samp_factor=1 gst-launch filesrc location=test_1152_864_11_11_11.jpeg ! jpegdec ! fakesink r_h = 1, r_v = 1 num_components=3, comps_in_scan=3 [0] h_samp_factor=1, v_samp_factor=1 [1] h_samp_factor=1, v_samp_factor=1 [2] h_samp_factor=1, v_samp_factor=1 gst-launch filesrc location=Photo689.jpg ! jpegdec ! fakesink r_h = 2, r_v = 2 num_components=3, comps_in_scan=3 [0] h_samp_factor=2, v_samp_factor=2 [1] h_samp_factor=1, v_samp_factor=2 [2] h_samp_factor=1, v_samp_factor=2
Is it so that - the first one is 4:2:0 chroma subsampling - the 2nd one is ? - the 3rd one is 4:2:2 choma subsampling
Anyone? Is the attached picture in http://www.fourcc.org/yuv.php#UYVY format?
The subsampling of the attached picture 422. Your first test picture test_1152_864_22_11_11.jpeg is also 422, so that can't be the problem...
Arnout, the vertical sampling differs. The reason I am asking, is that I have a change that resolves the crash, but then the image has weired colors. Right now it crashes becasue we don't setup enough pointers for UV components.
Oh yes I misread the first one. The attached one is 422, of that I'm sure :-). The question whether it is UYVY is not really relevant: in JPEG, you just have the three components which can be mixed up in different SOS parts. However, it is possible that libjpeg extracts it as UYVY... Perhaps the best is to look at libjpeg's yuv-conversion to see how they interpret the output of the decoder.
This fixes it for me: commit 6ae6af9dab9f3f863485ce327c78aea4b447bf66 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Tue Oct 13 00:41:57 2009 +0100 jpegdec: fix crash for unusual vertical chroma subsampling factors Fixes #597351.