]> granicus.if.org Git - libjpeg-turbo/commitdiff
Fixed non-fatal out-of-bounds read in SSE2 SIMD code reported by valgrind when decomp...
authorDRC <dcommander@users.sourceforge.net>
Thu, 1 Dec 2011 11:11:29 +0000 (11:11 +0000)
committerDRC <dcommander@users.sourceforge.net>
Thu, 1 Dec 2011 11:11:29 +0000 (11:11 +0000)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@728 632fc199-4ca6-4c93-a231-07263d6284db

1  2 
ChangeLog.txt

diff --cc ChangeLog.txt
index e7b099eb11172bfc564fe3ba2fdbde6be7773dae,d482563e316acf978ae670240b7121d4816b9456..fe264d50da100634317d90bfcd512f9f609d0e1d
@@@ -1,34 -1,26 +1,40 @@@
 -1.0.2
 +1.1.2
  =====
  
 -[1] Added further protections against invalid Huffman codes.
 +[1] Eliminated errors in the output of jpegtran on Windows that occurred when
 +the application was invoked using I/O redirection
 +(jpegtran <input.jpg >output.jpg).
  
 -[2] The algorithm used by the SIMD quantization function cannot produce correct
 -results when the JPEG quality is >= 98 and the fast integer forward DCT is
 -used.  Thus, the non-SIMD quantization function is now used for those cases,
 -and libjpeg-turbo should now produce identical output to libjpeg v6b in all
 -cases.
 +[2] The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
 +support in libjpeg-turbo v1.1.0 introduced several new error constants in
 +jerror.h, and these were mistakenly enabled for all emulation modes, causing
 +the error enum in libjpeg-turbo to sometimes have different values than the
 +same enum in libjpeg.  This represents an ABI incompatibility, and it caused
 +problems with rare applications that took specific action based on a particular
 +error value.  The fix was to include the new error constants conditionally
 +based on whether libjpeg v7 or v8 emulation was enabled.
  
 -[3] Despite the above, the fast integer forward DCT still degrades somewhat for
 -JPEG qualities greater than 95, so TurboJPEG/OSS will now automatically use the
 -slow integer forward DCT when generating JPEG images of quality 96 or greater.
 -This reduces compression performance by as much as 15% for these high-quality
 -images but is necessary to ensure that the images are perceptually lossless.
 -It also ensures that the library can avoid the performance pitfall created by
 -[2].
 +[3] Fixed an issue whereby Windows applications that used libjpeg-turbo would
 +fail to compile if the Windows system headers were included before jpeglib.h.
 +This issue was caused by a conflict in the definition of the INT32 type.
  
 -[4] Fixed visual artifacts in grayscale JPEG compression caused by a typo in
 -the RGB-to-chrominance lookup tables.
 +[4] Fixed 32-bit supplementary package for amd64 Debian systems which was
 +broken by enhancements to the packaging system in 1.1.
 +
++[5] Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
++a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
++This was more of an annoyance than an actual bug, since it did not cause any
++actual run-time problems, but the issue showed up when running libjpeg-turbo in
++valgrind.  See http://crbug.com/72399 for more information.
++
 +
 +1.1.1
 +=====
 +
 +[1] Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
 +by tjEncodeYUV().
  
 -[5] libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
 +[2] libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
  markers found in the middle of the JPEG data stream during decompression.  It
  will now hand off decoding of a particular block to the unaccelerated Huffman
  decoder if an unexpected marker is found, so that the unaccelerated Huffman