#48 valgrind reports uninitialized data in decompression output

[Benjamin Gilbert]

Fedora package: libjpeg-turbo-1.2.1-1.fc17.x86_64

When decoding certain images with a non-unity scale_denom, valgrind complains about uninitialized bytes in the output buffer.

$ valgrind --quiet --track-origins=yes djpeg -scale 1/2 -outfile out.pnm sample.jpg
==31216== Syscall param write(buf) points to uninitialised byte(s)
==31216== at 0x3D1C8E4940: __write_nocancel (syscall-template.S:82)
==31216== by 0x3D1C875FC2: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1289)
==31216== by 0x3D1C875EA1: new_do_write (fileops.c:543)
==31216== by 0x3D1C876D44: _IO_do_write@@GLIBC_2.2.5 (fileops.c:516)
==31216== by 0x3D1C876A2F: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1371)
==31216== by 0x3D1C86C62C: fwrite (iofwrite.c:45)
==31216== by 0x401133: main (djpeg.c:595)
==31216== Address 0x4c1000f is not stack'd, malloc'd or (recently) free'd
==31216== Uninitialised value was created by a heap allocation
==31216== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==31216== by 0x3D284285E8: alloc_large (jmemmgr.c:376)
==31216== by 0x3D28428870: alloc_sarray (jmemmgr.c:453)
==31216== by 0x3D2841BCE7: jinit_d_main_controller (jdmainct.c:510)
==31216== by 0x3D2841EE15: jinit_master_decompress (jdmaster.c:437)
==31216== by 0x3D284160C4: jpeg_start_decompress (jdapistd.c:44)
==31216== by 0x4010EE: main (djpeg.c:586)
==31216==

[Benjamin Gilbert]

Sample image

[DRC]

I've seen this before, but I think it occurs with the regular libjpeg code as well. Can you confirm? I don't think it's a real bug but rather is due to valgrind not properly detecting when the bytes get initialized.

[Benjamin Gilbert]

Neither libjpeg 6b nor 8d produce the warning, at least with this particular image. OTOH, libjpeg-turbo 1.2.1 compiled from source does produce the warning, so the problem isn't in the Fedora packaging.

[DRC]

Can't reproduce using the sample image you attached. Again, I've seen this issue before, so I believe it's happening. It just seems to be inconsistent.

[DRC]

I don't have a lot of time to devote to this, so if you can provide any additional information or assistance with reproducing the problem, that would be great.

[Benjamin Gilbert]

I was also able to reproduce this with the sample image and libjpeg-turbo 1.2.1 compiled on 32-bit Ubuntu 12.04.

How can I help? I'm willing to find a reproducer that works on your Linux distro, test alternative binaries, etc.

[DRC]

If you can figure out how to repro it on Centos or Red Hat Enterprise 5, that would greatly accelerate the process of getting a fix. I feel like it is probably a minor issue, but without a consistent way to reproduce it, it would require many hours of diagnosis, and I don't have those hours available right now.

[Benjamin Gilbert]

I have been unable to reproduce the problem on 32-bit CentOS 5.8.

On Fedora 17, I can consistently reproduce with Valgrind 3.7.0-4.fc17, and consistently cannot reproduce with Valgrind 3.8.1-4.fc17 and the same binary. Ubuntu 12.04 also ships Valgrind 3.7.0; CentOS 5 ships 3.5.0. I think this is a Valgrind issue, not a libjpeg-turbo bug.

[DRC]

OK, closing for now. If the situation changes, we can re-open it.

[Benjamin Gilbert]

I found another reproducer:

$ valgrind --quiet --track-origins=yes djpeg -scale 1/4 -outfile /dev/null sample-2.jpg 
==14606== Syscall param write(buf) points to uninitialised byte(s)
==14606==    at 0x514F230: __write_nocancel (in /lib64/libc-2.5.so)
==14606==    by 0x50F2BB2: _IO_file_write@@GLIBC_2.2.5 (in /lib64/libc-2.5.so)
==14606==    by 0x50F2AC5: _IO_do_write@@GLIBC_2.2.5 (in /lib64/libc-2.5.so)
==14606==    by 0x50F30F6: _IO_file_sync@@GLIBC_2.2.5 (in /lib64/libc-2.5.so)
==14606==    by 0x50E819F: fflush (in /lib64/libc-2.5.so)
==14606==    by 0x403C3C: finish_output_ppm (wrppm.c:206)
==14606==    by 0x401D64: main (djpeg.c:652)
==14606==  Address 0x401f00c is not stack'd, malloc'd or (recently) free'd
==14606==  Uninitialised value was created by a heap allocation
==14606==    at 0x4C241C6: malloc (vg_replace_malloc.c:296)
==14606==    by 0x4E616E9: alloc_large (jmemmgr.c:376)
==14606==    by 0x4E61904: alloc_sarray (jmemmgr.c:452)
==14606==    by 0x4E4D305: jinit_d_main_controller (jdmainct.c:510)
==14606==    by 0x4E50E6E: master_selection (jdmaster.c:573)
==14606==    by 0x4E50E6E: jinit_master_decompress (jdmaster.c:736)
==14606==    by 0x4E45E9F: jpeg_start_decompress (jdapistd.c:45)
==14606==    by 0x401D19: main (djpeg.c:629)
==14606== 

This is on 64-bit RHEL 5.11, with libjpeg-turbo 1.3.90 and Valgrind 3.10.0 installed from source. I can also reproduce this on 32-bit RHEL 5.11, and with libjpeg-turbo 1.3.1. Valgrind 3.5.0, as shipped with RHEL 5, does not produce the warning.

[Benjamin Gilbert]

Apparently SourceForge mangled the sample from my previous message. Here it is in a tarball.

I can still reproduce with 64-bit RHEL 5.11, Valgrind 3.10.1, and libjpeg-turbo 1.4.0. The problem goes away when built --without-simd.

Please reopen the bug if you think this is worth pursuing. Otherwise I'll desist and update my valgrind suppressions. :-)

[DRC]

I was able to repro it using the later version of valgrind, and I narrowed it down to something in simd/jdcolext-sse2[-64].asm. As to what that something is, I don't know, and I unfortunately don't have time to look into it in detail right now.

[DRC]

Note that valgrind 3.7.0 is the earliest version that reproduces this.