1379663 - Update libjpeg-turbo to 1.5.2

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

This is a (semi-)automated bug making you aware that there is an available upgrade for an embedded third-party library. You can leave this bug open, and it will be updated if a newer version of the library becomes available. If you close it as WONTFIX, please indicate if you do not wish to receive any future bugs upon new releases of the library.

libjpeg-turbo is currently at version 1.5.1 in mozilla-central, and the latest version of the library released is 1.5.2. 

I fetched the latest version of the library from https://github.com/libjpeg-turbo/libjpeg-turbo/.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

I'm not sure any of the fixed issues are actually relevant to us, but *shrug*. I can do the update at some point this week. The first fixed item was actually reported by us when updating to 1.5.1, but we just backported the upstream fix when we landed it.

-------------

Significant changes relative to 1.5.1:

* Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from building with Android NDK platforms prior to android-21 (5.0).

* Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD code in libjpeg-turbo from building.

* Fixed a regression introduced by 1.5 beta1[11] that prevented the Java version of TJBench from outputting any reference images (the -nowrite switch was accidentally enabled by default.)

* libjpeg-turbo should now build and run with full AltiVec SIMD acceleration on PowerPC-based AmigaOS 4 and OpenBSD systems.

* Fixed build and runtime errors on Windows that occurred when building libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory source/destination managers. Due to an oversight, the jpeg_skip_scanlines() and jpeg_crop_scanlines() functions were not being included in jpeg7.dll when libjpeg-turbo was built with -DWITH_JPEG7=1 and -DWITH_MEMSRCDST=1.

* Fixed "Bogus virtual array access" error that occurred when using the lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was built with libjpeg v7 API/ABI emulation. This was apparently a long-standing bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation in libjpeg-turbo v1.1.

* The lossless transform features in jpegtran and the TurboJPEG API will now always attempt to adjust the EXIF image width and height tags if the image size changed as a result of the transform. This behavior has always existed when using libjpeg v8 API/ABI emulation. It was supposed to be available with libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. Furthermore, there was never any good reason not to enable it with libjpeg v6b API/ABI emulation, since the behavior is entirely internal. Note that -copy all must be passed to jpegtran in order to transfer the EXIF tags from the source image to the destination image.

* Fixed several memory leaks in the TurboJPEG API library that could occur if the library was built with certain compilers and optimization levels (known to occur with GCC 4.x and clang with -O1 and higher but not with GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error after a TurboJPEG API function allocated a local buffer.

* The libjpeg-turbo memory manager will now honor the max_memory_to_use structure member in jpeg_memory_mgr, which can be set to the maximum amount of memory (in bytes) that libjpeg-turbo should use during decompression or multi-pass (including progressive) compression. This limit can also be set using the JPEGMEM environment variable or using the -maxmemory switch in cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) This has been a documented feature of libjpeg since v5, but the malloc()/free() implementation of the memory manager (jmemnobs.c) never implemented the feature. Restricting libjpeg-turbo's memory usage is useful for two reasons: it allows testers to more easily work around the 2 GB limit in libFuzzer, and it allows developers of security-sensitive applications to more easily defend against one of the progressive JPEG exploits (LJT-01-004) identified in this report.

* TJBench will now run each benchmark for 1 second prior to starting the timer, in order to improve the consistency of the results. Furthermore, the -warmup option is now used to specify the amount of warmup time rather than the number of warmup iterations.

* Fixed an error (short jump is out of range) that occurred when assembling the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a regression introduced by 1.5 beta1[12].

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Attachment: update libjpeg-turbo to version 1.5.2

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b069c77a1ff908f5185b199f2df0c1565f361cc9

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7534510da000
Update libjpeg-turbo to version 1.5.2. r=jrmuizel

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/7534510da000