Bug 819084 - ImageIcon: data corruption while loading jpeg
ImageIcon: data corruption while loading jpeg
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Pavel Tisnovsky
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-04 15:30 EDT by Giulio Bernardi
Modified: 2013-11-26 08:37 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-26 08:37:50 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The test program showing the bug (651 bytes, text/x-java)
2012-05-04 15:30 EDT, Giulio Bernardi
no flags Details
The test image (21.24 KB, image/jpeg)
2012-05-04 15:31 EDT, Giulio Bernardi
no flags Details
New JPEG converted with GraphicsMagick (8.76 KB, image/jpeg)
2012-05-11 11:19 EDT, J. Lewis Muir
no flags Details

  None (edit)
Description Giulio Bernardi 2012-05-04 15:30:31 EDT
Created attachment 582195 [details]
The test program showing the bug

Description of problem:
When loading some jpeg images (see the attached file) using new ImageIcon(), image data is somewhat corrupted, leading to errors in native code (in libjpeg, called from sun.awt.image.JPEGImageDecoder.readImage).
There are no problems if using ImageIO.read().
The attached code works without problems under sun/oracle jvms 1.5.0_22, 1.6.0_32, 1.7.0_04-b20

An important issue is that the reported error isn't always the same: if I change the name of the file in the program (and rename the file on disk) the error is slightly different. If I put more "loadImageBad" calls errors are slightly different too: maybe it's due to a race condition?

Version-Release number of selected component (if applicable):
java-1.6.0-openjdk-1.6.0.0-65.1.11.1.fc16.x86_64

How reproducible:
Always (at least for me)

Steps to Reproduce:
1. Compile attached TestImageIcon.java
2. Put attached Test.jpg in the same directory
3. Run TestImageIcon
  
Actual results:
$ java -cp . TestImageIcon
Test.jpg
Corrupt JPEG data: 3997 extraneous bytes before marker 0xda

Expected results:
$ java -cp . TestImageIcon
Test.jpg

Additional info:
If the bug doesn't show up, try copy pasting loadImageBad("Test.jpg"); line multiple times, also changing the file name (after having copied the file) if necessary.
Comment 1 Giulio Bernardi 2012-05-04 15:31:36 EDT
Created attachment 582196 [details]
The test image
Comment 2 Deepak Bhole 2012-05-04 15:43:58 EDT
Looks like only 1.6 is affected. Can you reproduce this with java-1.7.0-openjdk? java-1.6.0-openjdk will no longer be in Fedora as of F17.
Comment 3 Giulio Bernardi 2012-05-04 16:02:56 EDT
(In reply to comment #2)
> Looks like only 1.6 is affected. Can you reproduce this with
> java-1.7.0-openjdk? java-1.6.0-openjdk will no longer be in Fedora as of F17.

Okay, I just installed
java-1.7.0-openjdk.x86_64 1:1.7.0.3-2.1.fc16.1
Double check:
$ java -version
java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc16.1-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

but the problem is still here:
$ java -cp . TestImageIcon
Test.jpg
Corrupt JPEG data: bad Huffman code
sun.awt.image.ImageFormatException: Bogus marker length
        at sun.awt.image.JPEGImageDecoder.readImage(Native Method)
        at sun.awt.image.JPEGImageDecoder.produceImage(JPEGImageDecoder.java:136)
        at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:269)
        at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:205)
        at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169)

As you can see, the error message is different here. Actually, I had this backtraces on 1.6 too with different images: it depends on how data was corrupted. Sometimes libjpeg reports data corruption on stderr and the java runtime discards the warning, sometimes if things are bad enough a java exception is raised.
Comment 4 Deepak Bhole 2012-05-08 13:16:03 EDT
Assigning to Pavel
Comment 5 J. Lewis Muir 2012-05-11 11:18:04 EDT
On Arch Linux with OpenJDK 7, I've come across this problem too and am able to reproduce the problem with the test image and program.  I also found that if I use GraphicsMagick (or ImageMagick) to convert the JPEG to a new JPEG, the new JPEG loads in Java without the error.  I'm not saying this is the solution, but it might help in tracking down the problem by having two images: one that works and one that doesn't.  I will attach Test-gm.jpg, the converted Test.jpg image that works.

$ java -version
java version "1.7.0_03-icedtea"
OpenJDK Runtime Environment (IcedTea7 2.1) (ArchLinux build 7.b147_2.1-3-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

$ gm -version | head -n 3
GraphicsMagick 1.3.15 2012-04-28 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2012 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.

$ gm convert Test.jpg Test-gm.jpg
$ mv Test.jpg Test-orig.jpg
$ ln -s Test-gm.jpg Test.jpg
$ java -cp . TestImageIcon
Test.jpg
$ echo $?
0
Comment 6 J. Lewis Muir 2012-05-11 11:19:47 EDT
Created attachment 583870 [details]
New JPEG converted with GraphicsMagick
Comment 7 Fedora End Of Life 2013-01-16 12:04:17 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Fedora End Of Life 2013-02-13 16:25:45 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 9 Deepak Bhole 2013-02-13 23:32:47 EST
Re-opening. If this is still happening, we need to fix it.
Comment 10 Pavel Tisnovsky 2013-11-26 08:37:50 EST
OpenJDK6 is no longer supported on Fedoras, but to check if everything is ok I tried the reproducer w/o any problems on following configurations:

Fedora 19 with:
java version "1.7.0_45"
OpenJDK Runtime Environment (fedora-2.4.3.0.fc19-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode)

RHEL 5 with:
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.1.el5_10-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
and
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.14) (rhel-1.42.1.11.14.el5_10-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

RHEL 6 with:
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.14) (rhel-1.42.1.11.14.el5_10-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Note You need to log in before you can comment on or make changes to this bug.