United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6547241 JPEGImageReader.readImage crash
JDK-6547241 : JPEGImageReader.readImage crash

Details
Type:
Bug
Submit Date:
2007-04-18
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
client-libs
OS:
linux,solaris_10,windows_xp
Sub-Component:
javax.imageio
CPU:
x86,sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2,1.4.2_08,5.0
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
This is radiance case 65442009

Data directory: /net/cores.central/cores/65442009/0417/pid_17782

(dbx) regs
current thread: t@133
current frame:  [8]
g0-g3    0x00000000 0x0002d000 0x00000000 0x80000000
g4-g7    0x02467fe8 0x0044eedc 0x00000000 0xfe2a9400
o0-o3    0x00000000 0x00000000 0x00000001 0x04d4fe70
o4-o7    0x04d4fd88 0x00000198 0xcf47f348 0xd26ba614
l0-l3    0xd26ec000 0x00000001 0x04d4fe88 0x04d4e340
l4-l7    0x04d500c4 0x03842c90 0x00000001 0xd26bae14
i0-i3    0x03842c90 0x04d4fe90 0x045f3658 0x04d500a4
i4-i7    0x00000198 0x049940c0 0xcf47f3d8 0xd26ba3a8
y    0x00000000
psr  0xfe401000
pc   0xd26ba68c:SUNWprivate_1.1+0xa68c  ld       [%o0], %o0
npc  0xd26ba690:SUNWprivate_1.1+0xa690  st       %o0, [%fp - 20]

(dbx) where -l
current thread: t@133
  [1] libc.so.1:__lwp_kill(0x0, 0x6, 0xff09b96c, 0xa8350, 0xff36b298, 0x0), at
xff3412a4
  [2] libc.so.1:raise(0x6, 0x0, 0xff09d658, 0xffffffff, 0xff368284, 0x6), at 0x
f2dfe18
  [3] libc.so.1:abort(0x0, 0x1, 0xff09b96c, 0xa8350, 0xff36b298, 0x0), at 0xff2
0038
  [4] libjvm.so:os::abort(0x1, 0xff15b85e, 0xcf47e5d0, 0xff188000, 0xff1cfce4,
x3f40ec), at 0xff09d658
  [5] libjvm.so:os::handle_unexpected_exception(0x2467fe8, 0xb, 0xd26ba68c, 0xc
47f2c8, 0x32d54, 0xff36ce80), at 0xff09b96c
  [6] libjvm.so:JVM_handle_solaris_signal(0xd26ba68c, 0xff15d339, 0xcf47f010, 0
1, 0xd26ba690, 0xcf47f010), at 0xfedd82ec
  [7] libc.so.1:__sighndlr(0xb, 0xcf47f2c8, 0xcf47f010, 0xfedd79f4, 0x0, 0x1),
t 0xff3401dc
  ---- called from signal handler with signal 11 (SIGSEGV) ------
=>[8] 0xd26ba68c(0x0, 0x0, 0x1, 0x4d4fe70, 0x4d4fd88, 0x198), at 0xd26ba68c
  [9] 0xd26ba614(0x3842c90, 0x4d4fe90, 0x45f3658, 0x4d500a4, 0x198, 0x49940c0),
at 0xd26ba614
  [10] 0xd26ba3a8(0x6, 0x1, 0x1, 0x4d4fe70, 0x1, 0x198), at 0xd26ba3a8
  [11] 0xd26ba1c8(0x3842c90, 0xcf47f670, 0xcf47f514, 0x1, 0xcf47f75c, 0x3), at
xd26ba1c8
  [12] 0xd26ba170(0x3842c90, 0xcf47f670, 0x1, 0xd, 0x0, 0x3), at 0xd26ba170
  [13] libjpeg.so:Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage(0
0, 0x3a71228, 0x3, 0x9830e8, 0xcf47f75c, 0x3), at 0xd26bed6c
...

(dbx) whereis -a 0xd26ba68c
dbx: warning: unknown language, 'c' assumed
`libjpeg.so`SUNWprivate_1.1+0xa68c


hs_err_pid17782.log:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xD26BA68C
Function=[Unknown. Nearest: Java_sun_awt_image_JPEGImageDecoder_readImage+0x7A90
]
Library=/u01/app/oracle/product/10.1.2/ocsapps/jdk/jre/lib/sparc/libjpeg.so

Current Java thread:
    at com.sun.imageio.plugins.jpeg.JPEGImageReader.readImage(Native Method)
    at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader
.java:1053)
    at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:85
3)
    at oracle.imt.dscodec.renderer.memory.JpegReader.produceImage(JpegReader.jav
a:72)
    at oracle.imt.dscodec.renderer.memory.VirtualScreenRenderer.drawJpegFull(Vir
tualScreenRenderer.java:329)
    at oracle.imt.dscodec.cube.CubeParser.readImageJpeg(CubeParser.java:927)
    at oracle.imt.dscodec.cube.CubeParser.receiveDataNoResetFlag(CubeParser.java
:1223)
    at oracle.imt.dscodec.cube.CubeParser.receiveData(CubeParser.java:1045)
    at oracle.imt.server.virtual_screen.dscodec.cube.RenderExecutable.execute(Re
nderExecutable.java:69)
    - locked <0xe1260918> (a java.lang.Object)
    at oracle.imt.transport.threadpool.RestrictedThreadPool$RestrictedExecutable
.execute(RestrictedThreadPool.java:128)
    at oracle.imt.imtserver.threadpool.LogBranchRestrictedThreadPool$LogBranchRe
strictedExecutable.execute(LogBranchRestrictedThreadPool.java:32)
    at oracle.imt.transport.threadpool.ThreadPool$WorkingThread.run(ThreadPool.j
ava:419)
    at java.lang.Thread.run(Thread.java:534)
Some more information from customer sent by ###@###.### :

The new set of corefiles which have comein today are uploaded at /net/cores/cores/0417 dir. They are in respectives directories, such as pid_17782, pid_801, pid_7219.

We have recommended them to put -Xcheck:jni options to catch any native method errors. Cu got another coredump with this flag setup. I will upload those files as well.

JNI_65442009_PID_22344_corefiles.tar.gz size: 24,650k
JNI_65442009_PID_22344_libraries.tar.gz size: 8,402k

The hs_err_pid22344.log was empty. Nothing was logged there.

                                    

Comments
EVALUATION

In order to avoid crashes caused by concurrent usage of certain reader or writer
instance from multiple threads, I suggest to check thread context on each public method invocation and fire IllegeStateException in case of detected concurrent usage.

According to J2DBench measurements, this change seems to have negligible
performance effect:
 
imageio.input.image.imageio.reader.tests.getImageMetadata,imageio.opts.size=1000:
Standard: 1.761817270 (var=0.15%) (100.0%)
Updated reader: 1.760925012 (var=0.56%) (99.95%)
imageio.input.image.imageio.reader.tests.getImageMetadata,imageio.opts.size=20:
Standard: 3.322174922 (var=9.13%) (100.0%)
Updated reader: 3.354252199 (var=7.19%) (100.97%)
imageio.input.image.imageio.reader.tests.getImageMetadata,imageio.opts.size=250:
Standard: 3.135130848 (var=0.19%) (100.0%)
Updated reader: 3.088413215 (var=1.36%) (98.51%)
imageio.input.image.imageio.reader.tests.getImageMetadata,imageio.opts.size=4000:
Standard: 0.263026052 (var=0.35%) (100.0%)
Updated reader: 0.265392422 (var=0.36%) (100.9%)
imageio.input.image.imageio.reader.tests.read,imageio.opts.size=1000:
Standard: 8592.471358 (var=1.86%) (100.0%)
Updated reader: 8732.777023 (var=1.59%) (101.63%)
imageio.input.image.imageio.reader.tests.read,imageio.opts.size=20:
Standard: 683.4794975 (var=40.7%) (100.0%)
Updated reader: 677.2563176 (var=46.13%) (99.09%)
imageio.input.image.imageio.reader.tests.read,imageio.opts.size=250:
Standard: 8057.150313 (var=2.2%) (100.0%)
Updated reader: 8256.346054 (var=1.56%) (102.47%)
imageio.input.image.imageio.reader.tests.read,imageio.opts.size=4000:
Standard: 4634.546683 (var=0.29%) (100.0%)
Updated reader: 4650.712140 (var=0.64%) (100.35%)

However, it seems to be helpful to prevent illegal concurrent usage.
                                     
2007-05-08
EVALUATION

This crash is likely to be side effect of reseting JPEGImageReader instance
while decoding is still in progress. In particular,  from the dump of the
jpeg_decompress_struct in the core files it seems that this structure was
just (re)initialized,  i.e the global_state field is set to DSTATE_START (0xc8)
and all fields that should be filled (at the time of processing the header)
are reset (to the NULL value).

Attempt to use NULL data result in crash.  For example, the core file for
pid7219 shows that crash happens due to null pointer do the jpeg_entropy_decoder
structure which should have been already initialized.  The state of core
for pid17782 is even more weird. Crash happens inside the decode_msu() routine
when we are trying to re-fill input buffer (macros BITREAD_LOAD_STATE) due
to null pointer to the jpeg_source_mger structure.

Note that it is extremely unlikely that these structures were never filled
with useful data because we are using them at previous steps of image
processing and  VM should have crashed there (due to deference of NULL pointer).

I can imagine two ways to get this illegal state:
- use same instance of JPEG image reader from multiple threads.
   Note that library itself is not designed to be thread safe and therefore
   it crashes sometimes. Unfortunately there is no testcase to confirm this
   conclusion. At the moment the only potential fix (actually workaround) I can
   suggest is to make public methods of ImageReader class synchronized.
   This should protect us against crashes like these. However, this does not
   solve problem fully. Concurrent access will result in illegal state exception
   instead of crash and application code might be not able to deal with it.
   The real solution is to avoid multi-threaded usage of ImageIO plugins.

- call methods like reset() or abort() form progress listener methods.
    This is already reported as CR 4874601.

Unfortunately, it is impossible to find what was real cause of the crash in this
particular case (provided core files are not enough).

Additional information is required. Testcase will work best.
                                     
2007-04-23



Hardware and Software, Engineered to Work Together