]> granicus.if.org Git - libjpeg-turbo/log
libjpeg-turbo
8 years agoTravis CI: Use correct key for this repository
DRC [Wed, 5 Oct 2016 17:38:59 +0000 (12:38 -0500)]
Travis CI: Use correct key for this repository

8 years agoAdd Travis CI config for Un*x pre-release builds
DRC [Sun, 2 Oct 2016 14:13:23 +0000 (09:13 -0500)]
Add Travis CI config for Un*x pre-release builds

8 years agoFix 32-bit non-SIMD FP regression tests
DRC [Tue, 4 Oct 2016 18:41:48 +0000 (13:41 -0500)]
Fix 32-bit non-SIMD FP regression tests

- Introduce a new FLOATTEST value ("387") on Un*x systems that will
  compare the floating point DCT/IDCT algorithms against the expected
  results from the C algorithms when built using 32-bit code and
  -mfpmath=387.
- Extend the Windows regression tests so that they work properly when
  building libjpeg-turbo with 32-bit code and without SIMD, using either
  Visual C++ (tested with 2008, 2010, 2015) or MinGW.

8 years agoFix broken build w/ Visual C++ < 2010
DRC [Tue, 4 Oct 2016 18:25:34 +0000 (13:25 -0500)]
Fix broken build w/ Visual C++ < 2010

Regression introduced by dfefba77520ded5c5fd4864e76352a5f3eb23e74
(Windows doesn't always have stdint.h.)

8 years agoFix broken MIPS build
DRC [Mon, 26 Sep 2016 22:59:14 +0000 (17:59 -0500)]
Fix broken MIPS build

Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152

Fixes #104

8 years agoFix UBSan warning in arithmetic decoder
DRC [Thu, 22 Sep 2016 19:38:51 +0000 (14:38 -0500)]
Fix UBSan warning in arithmetic decoder

Very similar to the ones that were fixed in the Huffman decoders in
8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a.  These are innocuous.

Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1304567.

8 years agoFix broken build with NDK platforms < android-21
DRC [Thu, 22 Sep 2016 19:19:29 +0000 (14:19 -0500)]
Fix broken build with NDK platforms < android-21

Regression introduced by a09ba29a55b9a43d346421210d94370065eeaf53

Fixes #103

8 years agoBump version to 1.5.2 to prepare for new commits
DRC [Thu, 22 Sep 2016 19:14:05 +0000 (14:14 -0500)]
Bump version to 1.5.2 to prepare for new commits

8 years agoREADME.md: Fix typo
Roberto Civille Rodrigues [Thu, 22 Sep 2016 03:42:25 +0000 (00:42 -0300)]
README.md: Fix typo

Introduced in 17de51835735e319ada5ca139a64227423946a8a

Closes #102

8 years agoARM64 NEON: Fix another ABI conformance issue 1.5.1
mayeut [Tue, 20 Sep 2016 19:06:24 +0000 (21:06 +0200)]
ARM64 NEON: Fix another ABI conformance issue

Based on
https://github.com/mayeut/libjpeg-turbo/commit/98a5a9dc899aa9265858a3cbe0a96289a31a1322
with wordsmithing by DRC.

In the AArch64 ABI, as in many others, it's forbidden to read/store data
below the stack pointer.  Some SIMD functions were doing just that
(stack pointer misuse) when trying to preserve callee-saved registers,
and this resulted in those registers being restored with incorrect
contents under certain circumstances.

This patch fixes that behavior, and callee-saved registers are now
stored above the stack pointer throughout the function call.  The patch
also removes register saving in places where it is unnecessary for this
ABI, or it makes use of unused scratch regiters instead of callee-saved
registers.

Fixes #97.  Closes #101.

Refer also to https://bugzilla.redhat.com/show_bug.cgi?id=1368569

8 years agoBuild: Remove ARMv6 support from 'make iosdmg'
DRC [Tue, 20 Sep 2016 03:47:18 +0000 (22:47 -0500)]
Build: Remove ARMv6 support from 'make iosdmg'

The last iDevice to require ARMv6 was the iPhone 3G, which required iOS
4.2.1 or older.  Our binaries have always required iOS 4.3 or newer,
so I'm not sure if the ARMv6 fork of our binaries was ever useful to
begin with.  In any case, if it ever was useful, it no longer is.  Fat
binaries can still be generated with ARMv6 support by invoking
{build_directory}/pkgscripts/makemacpkg manually.

8 years agoFix out-of-bounds write in partial decomp. feature
DRC [Fri, 9 Sep 2016 02:49:02 +0000 (21:49 -0500)]
Fix out-of-bounds write in partial decomp. feature

Reported by Clang UBSan (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1301252 for test image.)
This appears to be a legitimate bug introduced by
3ab68cf563f6edc2608c085f5c8b2d5d5c61157e.  Any component array, such
as first_MCU_col and last_MCU_col, should always be able to accommodate
MAX_COMPONENTS values.  The aforementioned test image had 8 components,
which was not enough to make the out-of-bounds write bust out of the
jpeg_decomp_master struct (and fortunately the memory after last_MCU_col
is an integer used as a boolean, so stomping on it will do nothing other
than change the decoder state.)  I crafted another special image that
has 10 components (the maximum allowable), but that was apparently not
enough to bust out of the allocated memory, either.  Thus, it is
posited that the security threat posed by this bug is either extremely
minimal or non-existent.

8 years agoSilence additional UBSan warnings
DRC [Fri, 9 Sep 2016 02:29:58 +0000 (21:29 -0500)]
Silence additional UBSan warnings

NOTE: The jdhuff.c/jdphuff.c warnings should have already been silenced
by 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a, but apparently I need to
be REALLY clear that I'm trying to do pointer arithmetic rather than
dereference an array.  Grrr...

Refer to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1301250
https://bugzilla.mozilla.org/show_bug.cgi?id=1301256

8 years agoFix unsigned int overflow in libjpeg memory mgr.
DRC [Wed, 7 Sep 2016 21:40:10 +0000 (16:40 -0500)]
Fix unsigned int overflow in libjpeg memory mgr.

When attempting to decode a malformed JPEG image (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1295044) with dimensions
61472 x 32800, the maximum_space variable within the
realize_virt_arrays() function will exceed the maximum value of a 32-bit
integer and will wrap around.  The memory manager subsequently fails
with an "Insufficient memory" error (case 4, in alloc_large()), so this
commit simply causes that error to be triggered earlier, before UBSan
has a chance to complain.

Note that this issue did not ever represent an exploitable security
threat, because the POSIX-based memory manager that we use doesn't ever
do anything meaningful with the value of maximum_space.
jpeg_mem_available() simply sets avail_mem = maximum_space, so the
subsequent behavior of the memory manager is the same regardless of
whether maximum_space is correct or not.  This commit simply removes a
UBSan warning in order to make it easier to detect actual security
issues.

8 years agoTurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs
DRC [Mon, 1 Aug 2016 16:22:24 +0000 (11:22 -0500)]
TurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs

Normally, 4:2:2 JPEGs have horizontal x vertical luminance,chrominance
sampling factors of 2x1,1x1, and 4:4:0 JPEGs have horizontal x vertical
luminance,chrominance sampling factors of 1x2,1x1.  However, it is
technically legal to create 4:2:2 JPEGs with sampling factors of
2x2,1x2 and 4:4:0 JPEGs with sampling factors of 2x2,2x1, since the
sums of the products of those sampling factors (2x2 + 1x2 + 1x2 and
2x2 + 2x1 + 2x1) are still <= 10.  The libjpeg API correctly decodes
such images, so the TurboJPEG API should as well.

Fixes #92

8 years agoSilence pedantic GCC6 code formatting warnings
DRC [Thu, 14 Jul 2016 18:36:47 +0000 (13:36 -0500)]
Silence pedantic GCC6 code formatting warnings

Apparently it's "misleading" to put two self-contained if statements
on a single line.  Who knew?

8 years agoUse plain upsampling if merged isn't accelerated
DRC [Thu, 14 Jul 2016 01:39:11 +0000 (20:39 -0500)]
Use plain upsampling if merged isn't accelerated

Currently, this only affects ARM, since it is the only platform that
accelerates YCbCr-to-RGB conversion but not merged upsampling.  Even if
"plain" upsampling isn't accelerated, the combination of accelerated
color conversion + unaccelerated plain upsampling is still faster than
the unaccelerated merged upsampling algorithms.

Closes #81

8 years agoImplement h1v2 fancy upsampling
Kornel Lesiński [Sun, 10 Jul 2016 18:01:51 +0000 (19:01 +0100)]
Implement h1v2 fancy upsampling

This allows fancy upsampling to be used when decompressing 4:2:2 images
that have been losslessly rotated or transposed.

(docs and comments added by DRC)

Based on https://github.com/pornel/libjpeg-turbo/commit/f63aca945debde07e7c6476a1f667b71728c3d44

Closes #89

8 years agoFix AArch64 ABI conformance issue in SIMD code
DRC [Wed, 13 Jul 2016 17:15:02 +0000 (12:15 -0500)]
Fix AArch64 ABI conformance issue in SIMD code

In the AArch64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use 64-bit
instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD
functions.  The code worked thus far only because the existing compiler
optimizers weren't smart enough to do anything else with the register in
question, so the upper 32 bits happened to be all zeroes.

The latest builds of Clang/LLVM have a smarter optimizer, and under
certain circumstances, it will attempt to load-combine adjacent 32-bit
integers from one of the libjpeg structures into a single 64-bit integer
and pass that 64-bit integer as a 32-bit argument to one of the SIMD
functions (which is allowed by the ABI, since the upper 32 bits of the
32-bit argument's register are undefined.)  This caused the
libjpeg-turbo regression tests to crash.

This patch tries to use the Wn registers whenever possible.  Otherwise,
it uses a zero-extend instruction to avoid using the upper 32 bits of
the 64-bit registers, which are not guaranteed to be valid for 32-bit
arguments.

Based on https://github.com/sebpop/libjpeg-turbo/commit/1fbae13021eb98f6fffdfaf8678fcdb00b0b04d9

Closes #91.  Refer also to android-ndk/ndk#110 and
https://llvm.org/bugs/show_bug.cgi?id=28393

8 years agoDon't install libturbojpeg.pc if TJPEG disabled
DRC [Wed, 13 Jul 2016 03:21:20 +0000 (22:21 -0500)]
Don't install libturbojpeg.pc if TJPEG disabled

8 years agoLinux/PPC: Only enable AltiVec if CPU supports it
DRC [Wed, 6 Jul 2016 16:58:28 +0000 (16:58 +0000)]
Linux/PPC: Only enable AltiVec if CPU supports it

This eliminates "illegal instruction" errors when running libjpeg-turbo
under Linux on PowerPC chips that lack AltiVec support (e.g. the old
7XX/G3 models but also the newer e5500 series.)

8 years agoARM/MIPS: Change the behavior of JSIMD_FORCE*
DRC [Thu, 7 Jul 2016 18:10:30 +0000 (13:10 -0500)]
ARM/MIPS: Change the behavior of JSIMD_FORCE*

The JSIMD_FORCE* environment variables previously meant "force the use
of this instruction set if it is available but others are available as
well", but that did nothing on ARM platforms, since there is only ever
one instruction set available.  Since the ARM and MIPS CPU feature
detection code is less than bulletproof, and since there is only one
SIMD instruction set (currently) supported on those platforms, it makes
sense for the JSIMD_FORCE* environment variables on those platforms to
actually force the use of the SIMD instruction set, thus bypassing the
CPU feature detection code.

This addresses a concern raised in #88 whereby parsing /proc/cpuinfo
didn't work within a QEMU environment.  This at least provides a
workaround, allowing users to force-enable or force-disable SIMD
instructions for ARM and MIPS builds of libjpeg-turbo.

8 years agoBump version to 1.5.1 to prepare for new commits
DRC [Wed, 6 Jul 2016 16:22:27 +0000 (16:22 +0000)]
Bump version to 1.5.1 to prepare for new commits

8 years ago1.5.0 1.5.0
DRC [Wed, 1 Jun 2016 03:53:17 +0000 (22:53 -0500)]
1.5.0

8 years agoBUILDING.md: More NASM/YASM clarifications
DRC [Wed, 1 Jun 2016 03:48:52 +0000 (22:48 -0500)]
BUILDING.md: More NASM/YASM clarifications

28d1a1300c6be7fc8614ed827eb56cd97cf84e76 introduced the line
"nasm.exe should be in your PATH".  This commit corrects an oversight in
8f1c0a681cd34e8e80ba7b06f356d6080a7172c9 /
e5091f2cf3b6ba747907012146df93df0d01ec85 whereby this line should have
been extended to include yasm.exe.

8 years agoFormat copyright headers more consistently
DRC [Tue, 24 May 2016 15:23:56 +0000 (10:23 -0500)]
Format copyright headers more consistently

The IJG convention is to format copyright notices as:

Copyright (C) YYYY, Owner.

We try to maintain this convention for any code that is part of the
libjpeg API library (with the exception of preserving the copyright
notices from Cendio's code verbatim, since those predate
libjpeg-turbo.)

Note that the phrase "All Rights Reserved" is no longer necessary, since
all Buenos Aires Convention signatories signed onto the Berne Convention
in 2000.  However, our convention is to retain this phrase for any files
that have a self-contained copyright header but to leave it off of any
files that refer to another file for conditions of distribution and use.
For instance, all of the non-SIMD files in the libjpeg API library refer
to README.ijg, and the copyright message in that file contains "All
Rights Reserved", so it is unnecessary to add it to the individual
files.

The TurboJPEG code retains my preferred formatting convention for
copyright notices, which is based on that of VirtualGL (where the
TurboJPEG API originated.)

8 years agoMerge branch '1.4.x'
DRC [Sat, 28 May 2016 23:19:45 +0000 (18:19 -0500)]
Merge branch '1.4.x'

8 years agoBUILDING.txt: Clarify NASM build requirements 1.4.x
DRC [Sat, 28 May 2016 23:08:22 +0000 (18:08 -0500)]
BUILDING.txt: Clarify NASM build requirements

The version requirements only apply to NASM (not YASM.)  Also, 2.11.09
was never actually released (the first release containing the OS X fix
is 2.12.)

8 years agoDon't allow opaque source/dest mgrs to be swapped
DRC [Wed, 11 May 2016 02:04:02 +0000 (21:04 -0500)]
Don't allow opaque source/dest mgrs to be swapped

Calling jpeg_stdio_dest() followed by jpeg_mem_dest(), or jpeg_mem_src()
followed by jpeg_stdio_src(), is dangerous, because the existing opaque
structure would not be big enough to accommodate the new source/dest
manager.  This issue was non-obvious to libjpeg-turbo consumers, since
it was only documented in code comments.  Furthermore, the issue could
also occur if the source/dest manager was allocated by the calling
program, but it was not allocated with enough space to accommodate the
opaque stdio or memory source/dest manager structs.  The safest thing to
do is to throw an error if one of these functions is called when there
is already a source/dest manager assigned to the object and it was
allocated elsewhere.

Closes #78, #79

8 years agoBuild: Add integer version macro to jconfig.h
DRC [Wed, 11 May 2016 00:36:34 +0000 (19:36 -0500)]
Build: Add integer version macro to jconfig.h

This makes it significantly easier to do conditional compilation based
on the libjpeg-turbo version.

Based on:
https://github.com/hasinoff/libjpeg-turbo/commit/e6d5b3e50b8b07488cb7b4d26ab2061685bc6875
https://github.com/hasinoff/libjpeg-turbo/commit/1394a89ba6f3cd8abb556c1b65bac4a5f09760d0

Closes #80

8 years agoBuild: Don't allow jpeg-7+ emul. w/o arith coding
DRC [Tue, 10 May 2016 01:00:46 +0000 (20:00 -0500)]
Build: Don't allow jpeg-7+ emul. w/o arith coding

The jpeg-7/jpeg-8 APIs/ABIs require arithmetic coding, and the jpeg-8
API/ABI requires the memory source/destination manager, so this commit
causes the build system to ignore --with-arith-enc/--without-arith-enc
and --with-arith-dec/--without-arith-dec (and the equivalent CMake
variables-- WITH_ARITH_ENC and WITH_ARITH_DEC) when v7/v8 API/ABI
emulation is enabled.  Furthermore, the CMake build system now ignores
WITH_MEM_SRCDST whenever WITH_JPEG8 is specified (the autotools build
system already did that.)

8 years agoARMv7 SIMD: Fix clang compatibility (Part 2)
mattsarett [Tue, 3 May 2016 14:33:43 +0000 (10:33 -0400)]
ARMv7 SIMD: Fix clang compatibility (Part 2)

GCC does support UAL syntax (strbeq) if the ".syntax unified" directive
is supplied.  This directive is supported by all versions of GCC and
clang going back to 2003, so it should not create any backward
compatibility issues.

Based on https://github.com/mattsarett/libjpeg-turbo/commit/1264349e2fa6f098178c37abfa7b059ad8b405a2

Closes #76

8 years agoARMv7 SIMD: Fix clang compatibility
mattsarett [Mon, 2 May 2016 16:31:51 +0000 (12:31 -0400)]
ARMv7 SIMD: Fix clang compatibility

By design, clang only supports Unified Assembler Language (and not
pre-UAL syntax):
https://llvm.org/bugs/show_bug.cgi?id=23507
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/BABJIHGJ.html

Thus, clang only supports the strbeq instruction and not streqb, but
unfortunately some versions of GCC only support streqb.  Go, go
Gadget #ifdef...

Based on https://github.com/mattsarett/libjpeg-turbo/commit/a82e63aac63f8fa3
95fa4caad4de6859623ee2e2

Closes #75

8 years agoMerge branch '1.4.x'
DRC [Sun, 1 May 2016 17:07:05 +0000 (12:07 -0500)]
Merge branch '1.4.x'

8 years agoFix CMake fallback BUILD var on non-U.S. machines
DRC [Sun, 1 May 2016 16:42:15 +0000 (11:42 -0500)]
Fix CMake fallback BUILD var on non-U.S. machines

If wmic.exe wasn't available, then CMakeLists.txt would call
"cmd /C date /T" and parse the result in order to set the BUILD
variable.  However, the parser assumed that the date was in MM/DD/YYYY
format, which is not generally the case unless the user's locale is U.S.
English with the default region/language settings for that locale.

This commit modifies CMakeLists.txt such that it uses the
string(TIMESTAMP) function available in CMake 2.8.11 and later to set
the BUILD variable, thus eliminating the need to use wmic.exe or any
other platform-specific hack.

This commit also modifies the build instructions to remove any reference
to CMake 2.6 (which hasn't been supported by our build system since
libjpeg-turbo 1.3.x.)

Closes #74

8 years agoMerge branch '1.4.x'
DRC [Tue, 26 Apr 2016 00:08:47 +0000 (19:08 -0500)]
Merge branch '1.4.x'

8 years agoCMakeLists.txt: Clarify that Un*x isn't supported
DRC [Mon, 25 Apr 2016 23:16:46 +0000 (18:16 -0500)]
CMakeLists.txt: Clarify that Un*x isn't supported

At one time, it was possible to use CMake to build under Cygwin, but
that hasn't worked since 1.4.1 (due to the Huffman codec changes that
now require SIZEOF_SIZE_T to be defined for non-WIN32 platforms) and may
have even been broken before that.  Originally, we used the "date"
command under MSYS in order to obtain the default build number, but that
was rendered unnecessary by 5e3bb3e9 (v1.3 beta.)  9fe22dac (1.4 beta)
further modified CMakeLists.txt so that the "date" command was only used
on Cygwin, but for unexplained reasons, that commit also applied the
(now vestigial) code to all non-WIN32 platforms.  This prevented
CMakeLists.txt from displaying an error if someone attempted to use the
CMake build system on Un*x platforms, and that may have been behind the
flurry of pull requests and issues-- including #21, #29, #37, #58, #73--
complaining that the CMake build system didn't work on Un*x platforms
(although it was not until #73 that this bug came to light.)

This commit removes all vestiges of Un*x support from the CMake build
system and makes it clear that CMake cannot be used to build
libjpeg-turbo on non-WIN32 platforms.  It is our position that CMake
will not be supported on non-WIN32 platforms until/unless the autotools
build system is removed, and this will not happen without broad support
from the community (including major O/S vendors.)  If you are in favor
of migrating the entire build system to CMake, then please make your
voice heard by commenting on #56.

8 years agoCatch libjpeg errors in tjDecompressToYUV2()
DRC [Wed, 20 Apr 2016 16:27:42 +0000 (11:27 -0500)]
Catch libjpeg errors in tjDecompressToYUV2()

Even though tjDecompressToYUV2() is mostly just a wrapper for
tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls
jpeg_read_header(), so it needs to properly set up the libjpeg error
handler prior to making this call.  Otherwise, under very esoteric (and
arguably incorrect) use cases, a program could call tjDecompressToYUV2()
without first checking the JPEG header using tjDecompressHeader3(), and
if the header was corrupt, then the libjpeg API would invoke
my_error_exit().  my_error_exit() would in turn call longjmp() on the
previous value of myerr->setjmp_buffer, which was probably set in a
previous TurboJPEG function, such as tjInitDecompress().  Thus, when a
libjpeg error was triggered within the body of tjDecompressToYUV2(), the
PC would jump to the error handler of the previous TurboJPEG function,
and this usually caused stack corruption in the calling program (because
the signature and return type of the previous TurboJPEG function
probably wasn't the same as that of tjDecompressToYUV2().)

8 years agoIncrease severity of tjDecompressToYUV2() bug desc
DRC [Thu, 21 Apr 2016 15:22:36 +0000 (10:22 -0500)]
Increase severity of tjDecompressToYUV2() bug desc

Actually, what happened was that the longjmp() call within
my_error_exit() acted on the previous value of myerr->setjmp_buffer,
which was probably set in a previous TurboJPEG function, such as
tjInitDecompress().  Thus, when a libjpeg error was triggered within
the body of tjDecompressToYUV2(), the PC jumped to the error handler
of the previous TurboJPEG function, and this usually caused stack
corruption in the calling program (because the signature and return
type of the previous TurboJPEG function probably wasn't the same.)

8 years agoCatch libjpeg errors in tjDecompressToYUV2()
DRC [Wed, 20 Apr 2016 16:27:42 +0000 (11:27 -0500)]
Catch libjpeg errors in tjDecompressToYUV2()

Even though tjDecompressToYUV2() is mostly just a wrapper for
tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls
jpeg_read_header(), so it needs to properly set up the libjpeg error
handler prior to making this call.  Otherwise, under very esoteric (and
arguably incorrect) use cases, a program can call tjDecompressToYUV2()
without first checking the JPEG header using tjDecompressHeader3(), and
if the header is corrupt, tjDecompressToYUV2() will abort without
triggering an error.

Fixes #72

8 years agoBUILDING.md: Fix "... OR ..." indentation again
DRC [Thu, 14 Apr 2016 19:19:19 +0000 (14:19 -0500)]
BUILDING.md: Fix "... OR ..." indentation again

<sigh> GitHub doesn't render indented text the same as my local MarkDown
viewer (MacDown), so it's necessary to indent "... OR ..." by 3 spaces
so both will display it on the same indentation level as "Visual C++
2005 or later" and "MinGW".

8 years agoBUILDING.md: Fix confusing Windows build reqs
DRC [Thu, 14 Apr 2016 19:12:46 +0000 (14:12 -0500)]
BUILDING.md: Fix confusing Windows build reqs

Indent "... OR ..." to make it clear that the choice is between Visual
C++ and MinGW, not Visual C++ and MinGW + NASM.  Move NASM to the top of
the list to make that even more clear.  Make it clear that nasm.exe
should be in the PATH.

Addresses concerns raised in #70

8 years agoMerge branch '1.4.x'
DRC [Thu, 31 Mar 2016 15:02:44 +0000 (10:02 -0500)]
Merge branch '1.4.x'

8 years agocjpeg: Fix buf overrun caused by bad bin PPM input
DRC [Thu, 31 Mar 2016 14:49:49 +0000 (09:49 -0500)]
cjpeg: Fix buf overrun caused by bad bin PPM input

This extends the fix in 6709e4a0cfa44d4f54ee8ad05753d4aa9260cb91 to
include binary PPM/PGM files, thus preventing a malformed binary
PPM/PGM input file from triggering an overrun of the rescale array and
potentially crashing cjpeg.

Note that this issue affected only cjpeg and not the underlying
libjpeg-turbo libraries, and thus it did not represent a security
threat.

Thanks to @hughdavenport for the discovery.

8 years agoMerge branch '1.4.x'
DRC [Wed, 16 Mar 2016 12:18:30 +0000 (07:18 -0500)]
Merge branch '1.4.x'

8 years agoAdd version/build info to global string table
DRC [Wed, 16 Mar 2016 12:10:35 +0000 (07:10 -0500)]
Add version/build info to global string table

This is a common practice in other infrastructure libraries, such as
OpenSSL and libpng, because it makes it easy to examine an application
binary and determine which version of the library the application was
linked against.

Closes #66

8 years agoChangeLog.md: Improve readability of plain text
DRC [Mon, 14 Mar 2016 18:32:00 +0000 (13:32 -0500)]
ChangeLog.md: Improve readability of plain text

8 years agochange.log: Refer users to ChangeLog.md
DRC [Sun, 13 Mar 2016 23:28:14 +0000 (18:28 -0500)]
change.log: Refer users to ChangeLog.md

change.log is included only to document the changes that we have merged
from libjpeg.

8 years agoMarkdown version of ChangeLog.txt
DRC [Sun, 13 Mar 2016 21:24:48 +0000 (16:24 -0500)]
Markdown version of ChangeLog.txt

This will make it easier to crib ChangeLog information into release
notes, since both SourceForge and GitHub support MD.

8 years agoRename ChangeLog.txt
DRC [Sun, 13 Mar 2016 17:36:06 +0000 (12:36 -0500)]
Rename ChangeLog.txt

... in preparation for creating a MarkDown version (Git will not
preserve history unless you rename the file prior to modifying it.)

8 years agoREADME.md: Link to BUILDING.md
DRC [Fri, 11 Mar 2016 17:14:28 +0000 (11:14 -0600)]
README.md: Link to BUILDING.md

Addresses a concern expressed in #56 and #58.

8 years agoBUILDING.md and README.md: Cosmetic tweaks
DRC [Wed, 9 Mar 2016 23:23:45 +0000 (17:23 -0600)]
BUILDING.md and README.md: Cosmetic tweaks

8 years agoChangeLog: "1.5 beta1" --> "1.4.90 (1.5 beta1)"
DRC [Sun, 6 Mar 2016 14:34:48 +0000 (08:34 -0600)]
ChangeLog: "1.5 beta1" --> "1.4.90 (1.5 beta1)"

(for consistency with other beta release headings)

8 years agoMerge branch '1.4.x'
DRC [Sun, 6 Mar 2016 14:33:02 +0000 (08:33 -0600)]
Merge branch '1.4.x'

8 years agoEnsure that default Huffman tables are initialized
DRC [Sun, 6 Mar 2016 14:15:04 +0000 (08:15 -0600)]
Ensure that default Huffman tables are initialized

This prevents a malformed motion-JPEG frame (MJPEG frames lack Huffman
tables) from causing the "fast path" of the Huffman decoder to read
uninitialized memory.  Essentially, this is doing the same thing for
MJPEG frames as 43d8cf4d4572fa50a37cccadbe71b9bee37de55d did for regular
images.

8 years agoJava: Fix parallel make with autotools
DRC [Wed, 2 Mar 2016 15:53:11 +0000 (09:53 -0600)]
Java: Fix parallel make with autotools

Running 'make -j{jobs}' on a build that was configured with Java
(--with-java) would previously cause an error:

    make: *** No rule to make target `TJExample.class', needed by
        `turbojpeg.jar'.

It seems that parallel make doesn't understand that the files in
$(JAVA_CLASSES) are all generated from the same invocation of javac, so
it tries to parallelize the building of those files (which of course
doesn't work.)  This patch instead makes turbojpeg.jar depend on
classnoinst.stamp.  This effectively creates a synchronization fence,
since that file is only created when all of the class files have been
built.

Fixes #62

8 years agoWin/x64: Fix improper callee save of xmm8-xmm11 1.4.90
DRC [Mon, 29 Feb 2016 23:21:02 +0000 (17:21 -0600)]
Win/x64: Fix improper callee save of xmm8-xmm11

The x86-64 SIMD accelerations for Huffman encoding used incorrect
stack math to save xmm8-xmm11 on Windows.  This caused TJBench to
always report 1 Mpixel/sec for the compression performance, and it
likely would have caused other application issues as well.

8 years agoBump TurboJPEG C API revision to 1.5
DRC [Mon, 29 Feb 2016 19:18:01 +0000 (13:18 -0600)]
Bump TurboJPEG C API revision to 1.5

The changes relative to 1.4.x are only cosmetic (using const pointers)
and should not affect API/ABI compatibility, but our practice is to
synchronize the API revision with the most recent release that provides
user-visible changes to the API.

8 years agoChangeLog: Mention jpeg_crop_scanline() function
DRC [Mon, 29 Feb 2016 18:06:33 +0000 (12:06 -0600)]
ChangeLog: Mention jpeg_crop_scanline() function

8 years ago1.5 beta1
DRC [Mon, 29 Feb 2016 17:12:44 +0000 (11:12 -0600)]
1.5 beta1

8 years agoMerge branch '1.4.x'
DRC [Thu, 25 Feb 2016 23:15:21 +0000 (17:15 -0600)]
Merge branch '1.4.x'

8 years agoFix memory leak when running tjunittest -yuv
mayeut [Thu, 25 Feb 2016 22:14:45 +0000 (23:14 +0100)]
Fix memory leak when running tjunittest -yuv

Closes #61

8 years agoFix v7/v8-compatible build
DRC [Mon, 22 Feb 2016 16:00:19 +0000 (10:00 -0600)]
Fix v7/v8-compatible build

Broken by 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e

Fixes #60

8 years agolibjpeg API: Partial scanline decompression
DRC [Sat, 20 Feb 2016 00:32:10 +0000 (18:32 -0600)]
libjpeg API: Partial scanline decompression

This, in combination with the existing jpeg_skip_scanlines() function,
provides the ability to crop the image both horizontally and vertically
while decompressing (certain restrictions apply-- see libjpeg.txt.)

This also cleans up the documentation of the line skipping feature and
removes the "strip decompression" feature from djpeg, since the new
cropping feature is a superset of it.

Refer to #34 for discussion.

Closes #34

8 years agoBuild: Make the NASM autoconf variable persistent
DRC [Fri, 19 Feb 2016 19:16:56 +0000 (13:16 -0600)]
Build: Make the NASM autoconf variable persistent

Previously, if a custom value of this variable was specified when
running configure, then that value would be lost if configure was
automatically re-run (as a result of changes to configure.ac, for
instance.)

As a bonus, the NASM variable is now also listed when running
'configure --help', so it is obvious how to override the default
NASM command.

8 years agoUse consistent/modern code formatting for dbl ptrs
DRC [Fri, 19 Feb 2016 16:56:13 +0000 (10:56 -0600)]
Use consistent/modern code formatting for dbl ptrs

8 years agousage.txt: Restore accidentally deleted phrase
DRC [Fri, 19 Feb 2016 16:35:41 +0000 (10:35 -0600)]
usage.txt: Restore accidentally deleted phrase

It somehow got lost when merging the jpeg-9+ documentation changes.

8 years agoMore minor code formatting tweaks
DRC [Fri, 19 Feb 2016 16:35:09 +0000 (10:35 -0600)]
More minor code formatting tweaks

8 years agoClean up a couple of copyright messages
DRC [Fri, 19 Feb 2016 15:25:44 +0000 (09:25 -0600)]
Clean up a couple of copyright messages

8 years agoUse consistent/modern code formatting for pointers
DRC [Fri, 19 Feb 2016 14:53:33 +0000 (08:53 -0600)]
Use consistent/modern code formatting for pointers

The convention used by libjpeg:

    type * variable;

is not very common anymore, because it looks too much like
multiplication.  Some (particularly C++ programmers) prefer to tuck the
pointer symbol against the type:

    type* variable;

to emphasize that a pointer to a type is effectively a new type.
However, this can also be confusing, since defining multiple variables
on the same line would not work properly:

    type* variable1, variable2;  /* Only variable1 is actually a
                                    pointer. */

This commit reformats the entirety of the libjpeg-turbo code base so
that it uses the same code formatting convention for pointers that the
TurboJPEG API code uses:

    type *variable1, *variable2;

This seems to be the most common convention among C programmers, and
it is the convention used by other codec libraries, such as libpng and
libtiff.

8 years agoReorder copyright messages in cjpeg/djpeg/jpegtran
DRC [Thu, 18 Feb 2016 22:02:28 +0000 (16:02 -0600)]
Reorder copyright messages in cjpeg/djpeg/jpegtran

Place the authors in the following order:
* libjpeg-turbo authors (2009-) in descending order of the date of their
  most recent contribution to the project, then in ascending order of
  the date of their first contribution to the project
* Upstream authors in descending order of the date of the first
  inclusion of their code (this indicates that their code serves as the
  foundation of this code.)

This also adds Siarhei to the author list, since he contributed ARM SIMD
code both as a Nokia employee and more recently as an independent
developer.

8 years agoInclude some comments/doc tweaks from jpeg-9+
DRC [Thu, 18 Feb 2016 21:16:17 +0000 (15:16 -0600)]
Include some comments/doc tweaks from jpeg-9+

8 years agoWordsmith GIF limitations in cjpeg.1/djpeg.1
DRC [Thu, 18 Feb 2016 02:05:44 +0000 (20:05 -0600)]
Wordsmith GIF limitations in cjpeg.1/djpeg.1

8 years agoThe Independent JPEG Group's JPEG software v9b ijg
Guido Vollbeding [Sun, 17 Jan 2016 00:00:00 +0000 (00:00 +0000)]
The Independent JPEG Group's JPEG software v9b

8 years agoThe Independent JPEG Group's JPEG software v9a
Guido Vollbeding [Sun, 19 Jan 2014 00:00:00 +0000 (00:00 +0000)]
The Independent JPEG Group's JPEG software v9a

8 years agoThe Independent JPEG Group's JPEG software v9
Guido Vollbeding [Sun, 13 Jan 2013 00:00:00 +0000 (00:00 +0000)]
The Independent JPEG Group's JPEG software v9

8 years agoClean up pkgconfig dir when removing RPM & Mac pkg
DRC [Sun, 14 Feb 2016 23:20:30 +0000 (17:20 -0600)]
Clean up pkgconfig dir when removing RPM & Mac pkg

8 years agoFix compiler warning
DRC [Sun, 14 Feb 2016 15:01:07 +0000 (09:01 -0600)]
Fix compiler warning

8 years agoWin: Display effective C/LD flags in CMake output
DRC [Wed, 10 Feb 2016 00:27:27 +0000 (18:27 -0600)]
Win: Display effective C/LD flags in CMake output

8 years agoJava: Avoid OOM error when running 'make test'
DRC [Tue, 9 Feb 2016 07:35:39 +0000 (01:35 -0600)]
Java: Avoid OOM error when running 'make test'

We need to garbage collect between iterations of the outside loop in
bufSizeTest() in order to avoid exhausting the heap when running with
Java 6 (which is still used on Linux to test the 32-bit version of
libjpeg-turbo in automated builds.)

8 years agoARM64: Avoid tbl instruction on Cortex-A53/A57
DRC [Tue, 9 Feb 2016 06:38:58 +0000 (00:38 -0600)]
ARM64: Avoid tbl instruction on Cortex-A53/A57

Full-color compression speedups relative to previous commits:
Cortex-A53 (Nexus 5X), Android, 64-bit: 0.91-3.0% (avg. 1.8%)
Cortex-A57 (Nexus 5X), Android, 64-bit: -0.35-1.5% (avg. 0.65%)

8 years agoChangeLog: Mention ARM64 Huffman & adj perf claims
DRC [Mon, 8 Feb 2016 22:10:28 +0000 (16:10 -0600)]
ChangeLog: Mention ARM64 Huffman & adj perf claims

8 years agoFix iOS/ARMv8 build
DRC [Mon, 8 Feb 2016 21:15:11 +0000 (15:15 -0600)]
Fix iOS/ARMv8 build

Broken by 46ecffa324be43aab80f6160dc57d98b0a54a704.

gas-preprocessor.pl and/or the clang assembler apparently don't like
default values in macro arguments, and we need to use a separate const
section for each function (because of our use of adr, also necessitated
by the broken clang assembler.)

8 years agoBUILDING.md: Update OS X Java information
DRC [Mon, 8 Feb 2016 20:41:07 +0000 (14:41 -0600)]
BUILDING.md: Update OS X Java information

The Apple Java Developer Package is only necessary on OS X < 10.7.
When building on Lion and later, the Oracle JDK is preferred.

8 years agoFix 'make dist'; Include LICENSE.md in packages
DRC [Mon, 8 Feb 2016 20:03:13 +0000 (14:03 -0600)]
Fix 'make dist'; Include LICENSE.md in packages

8 years agoARM64: Avoid LD3/ST3 at run time, not compile time
DRC [Mon, 8 Feb 2016 04:05:56 +0000 (22:05 -0600)]
ARM64: Avoid LD3/ST3 at run time, not compile time

... and only if ThunderX is detected.  This can be easily expanded later
on to include other CPUs that are known to suffer from slow LD3/ST3, but
it doesn't make sense to disable LD3/ST3 for all non-Android Linux
platforms just because ThunderX is slow.

8 years agoARM64 NEON SIMD implementation of Huffman encoding
DRC [Mon, 8 Feb 2016 02:36:02 +0000 (20:36 -0600)]
ARM64 NEON SIMD implementation of Huffman encoding

Full-color compression speedups relative to previous commits:
Cortex-A53 (Nexus 5X), Android, 64-bit: 1.1-13% (avg. 6.0%)
Cortex-A57 (Nexus 5X), Android, 64-bit: 0.0-22% (avg. 6.3%)

Refer to #47 and #50 for discussion

Closes #50

Note that this commit introduces a similar /proc/cpuinfo parser to that
of the ARM32 implementation.  It is used to specifically check whether
the code is running on Cavium ThunderX and, if so, disable the ARM64
SIMD Huffman routines (which slow performance by an average of 8% on
that CPU.)

Based on:
https://github.com/mayeut/libjpeg-turbo/commit/a8c282e5e5ac10a715d6d6a9ab22121982b485f6

8 years agoARM SIMD: Comment tweaks
DRC [Sun, 7 Feb 2016 23:39:33 +0000 (17:39 -0600)]
ARM SIMD: Comment tweaks

8 years agoUn*x: Enable testing cross-compiled builds
DRC [Sat, 6 Feb 2016 22:04:29 +0000 (16:04 -0600)]
Un*x: Enable testing cross-compiled builds

Don't include the all: target as a dependency of the tests when
cross-compiling, and ensure that the files generated by the tests are
removed, even if they were created read-only (or if the tests are being
run on a different type of system that doesn't correctly interpret the
file permissions.)  This allows one to easily build the code on one
machine and run 'make test' on another.

8 years agoFix Visual C++ compiler warnings
DRC [Sat, 6 Feb 2016 22:03:57 +0000 (16:03 -0600)]
Fix Visual C++ compiler warnings

Somehow this got reverted with aa769febf25c64f115c2a237516b0c7d65f651cd.
Oops.

8 years agoWin: Enable testing cross-compiled builds
DRC [Sat, 6 Feb 2016 20:09:20 +0000 (14:09 -0600)]
Win: Enable testing cross-compiled builds

When cross-compiling, CMakeLists.txt now generates the CTest script
using relative paths, so that CTest can more easily be executed on a
different machine from the build machine.  Furthermore, Windows builds
are now tested using md5cmp, just like on Linux, rather than a CMake
script.  This prevents issues with differing CMake locations between
the build and test machines.

This also removes some trailing spaces from the md5cmp code and improves
the readability of the test code in CMakeLists.txt.

8 years agoFix MinGW build
DRC [Sat, 6 Feb 2016 18:18:44 +0000 (12:18 -0600)]
Fix MinGW build

jinclude.h can't be safely included multiple times, so instead of
including it in the shared (broken-out) headers, it should instead be
included by the source files that include one or more of those headers.

8 years agoUpdate MinGW Linux build recipe
DRC [Sat, 6 Feb 2016 18:17:40 +0000 (12:17 -0600)]
Update MinGW Linux build recipe

8 years agoMerge branch '1.4.x'
DRC [Fri, 5 Feb 2016 00:52:23 +0000 (18:52 -0600)]
Merge branch '1.4.x'

8 years agoMerge branch '1.3.x' into 1.4.x
DRC [Fri, 5 Feb 2016 00:47:07 +0000 (18:47 -0600)]
Merge branch '1.3.x' into 1.4.x

8 years agoMerge branch '1.2.x' into 1.3.x 1.3.x
DRC [Fri, 5 Feb 2016 00:46:13 +0000 (18:46 -0600)]
Merge branch '1.2.x' into 1.3.x

8 years agoPrevent overread when decoding malformed JPEG 1.2.x
DRC [Fri, 5 Feb 2016 00:34:38 +0000 (18:34 -0600)]
Prevent overread when decoding malformed JPEG

The accelerated Huffman decoder was previously invoked if there were
> 128 bytes in the input buffer.  However, it is possible to construct a
JPEG image with Huffman blocks > 430 bytes in length
(http://stackoverflow.com/questions/2734678/jpeg-calculating-max-size).
While such images are pathological and could never be created by a
JPEG compressor, it is conceivable that an attacker could use such an
artifially-constructed image to trigger an input buffer overrun in the
libjpeg-turbo decompressor and thus gain access to some of the data on
the calling program's heap.

This patch simply increases the minimum buffer size for the accelerated
Huffman decoder to 512 bytes, which should (hopefully) accommodate any
possible input.

This addresses a major issue (LJT-01-005) identified in a security audit
by Cure53.

8 years agoGuard against wrap-around in alloc functions
DRC [Thu, 4 Feb 2016 16:59:21 +0000 (10:59 -0600)]
Guard against wrap-around in alloc functions

Because of the exposed nature of the libjpeg API, alloc_small() and
alloc_large() can potentially be called by external code.  If an
application were to call either of those functions with
sizeofobject > SIZE_MAX - ALIGN_SIZE - 1, then the math in
round_up_pow2() would wrap around to zero, causing that function to
return a small value.  That value would likely not exceed
MAX_ALLOC_CHUNK, so the subsequent size checks in alloc_small() and
alloc_large() would not catch the error.

A similar problem could occur in 32-bit builds if alloc_sarray() were
called with
samplesperrow > SIZE_MAX - (2 * ALIGN_SIZE / sizeof(JSAMPLE)) - 1

This patch simply ensures that the size argument to the alloc_*()
functions will never exceed MAX_ALLOC_CHUNK (1 billion).  If it did,
then subsequent size checks would eventually catch that error, so we
are instead catching the error before round_up_pow2() is called.

This addresses a minor concern (LJT-01-001) expressed in a security
audit by Cure53.

8 years agoFix Visual C++ compiler warnings
DRC [Thu, 4 Feb 2016 16:58:10 +0000 (10:58 -0600)]
Fix Visual C++ compiler warnings

8 years agordppm.c: formatting tweaks
DRC [Thu, 4 Feb 2016 16:51:22 +0000 (10:51 -0600)]
rdppm.c: formatting tweaks