JDK-6547241 : JPEGImageReader.readImage crash
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 1.4.2,1.4.2_08,5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris_10,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2007-04-18
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other Other Other JDK 6 JDK 7
1.4.2_26-revFixed 1.4.2_27Fixed 5.0u26-revFixed 5.0u27Fixed 6u20-revFixed 7 b14Fixed
Related Reports
Relates :  
JDK-2191040 - Attempt to dispose jpeg reader form another thread may cause crash
Relates :  
JDK-6557086 - Attempt to dispose jpeg reader form another thread may cause crash
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.
08-05-2007
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.
23-04-2007