Issue Details (XML | Word | Printable)

Key: JAI_IMAGEIO_CORE-126
Type: Bug Bug
Status: Open Open
Priority: Blocker Blocker
Assignee: jxc
Reporter: gerardkoppelaar
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
jai-imageio-core

ACCESS_VIOLATION in clib_jiio_sse2.dll

Created: 24/Apr/07 08:12 AM   Updated: 13/Sep/07 04:42 PM
Component/s: codeclib
Affects Version/s: current
Fix Version/s: milestone 1

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive error2.zip (87 kB) 02/May/07 04:25 AM - gerardkoppelaar
2. Zip Archive imagetest.zip (200 kB) 26/Apr/07 07:43 AM - gerardkoppelaar
3. Zip Archive imagetest.zip (16 kB) 24/Apr/07 08:44 AM - gerardkoppelaar

Image Attachments:

1. nederlandwit.jpg
(34 kB)
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 126
Tags:
Participants: gerardkoppelaar and jxc


 Description  « Hide

Under heavy multi-threaded load, native sse2 library randomly fails and brings
down the whole JVM.

An example error dump is given here:

#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x3993ff2c, pid=2052, tid=1176
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode)
  4. Problematic frame:
  5. C [clib_jiio_sse2.dll+0xaff2c]
    #
  6. If you would like to submit a bug report, please visit:
  7. http://java.sun.com/webapps/bugreport/crash.jsp
    #

--------------- T H R E A D ---------------

Current thread (0x38dd0400): JavaThread "Process Image" daemon
[_thread_in_native, id=1176]

siginfo: ExceptionCode=0xc0000005, reading address 0x39dc9000

Registers:
EAX=0x39dc8ff4, EBX=0x39dc85f4, ECX=0x39ee3bee, EDX=0x00000134
ESP=0x392af6a0, EBP=0x392af81c, ESI=0x39dc7bf4, EDI=0x00000130
EIP=0x3993ff2c, EFLAGS=0x00010212

Top of Stack: (sp=0x392af6a0)
0x392af6a0: 00d7c2b8 00d7c2b8 00d7c2b8 00d7c2b8
0x392af6b0: 00d7c2b8 00d7c2b8 00d7c2b8 0099e48e
0x392af6c0: 00000140 00000138 00000000 39dc7be8
0x392af6d0: 39dc84c0 39ee3bee 0000008b 00000073
0x392af6e0: 00000025 00000025 39dc8ec0 dc72c4df
0x392af6f0: 00c100c1 00c100c1 00c300c3 00c100c2
0x392af700: 00c000c0 00c100c1 00c300c3 00c200c2
0x392af710: 00c300c2 00c400c4 00c200c2 00c200c2

Instructions: (pc=0x3993ff2c)
0x3993ff1c: 66 0f e0 e3 66 0f 60 d4 66 0f 60 c2 66 0f 68 f2
0x3993ff2c: f3 0f 6f 20 66 0f 6f d4 66 0f 6f dc 83 c3 06 66

Stack: [0x39260000,0x392b0000), sp=0x392af6a0, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [clib_jiio_sse2.dll+0xaff2c]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J com.sun.medialib.codec.jpeg.Decoder.njpeg_decode(J[I)V
J com.sun.medialib.codec.jpeg.Decoder.decode(Lcom/sun/medialib/codec/jiio/
mediaLibImage;)Lcom/sun/medialib/codec/jiio/mediaLibImage;
J com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageReader.decode(Ljava/io/
InputStream;)Lcom/sun/medialib/codec/jiio/mediaLibImage;
J com.sun.media.imageioimpl.plugins.clib.CLibImageReader.getImage(I)Lcom/sun/
medialib/codec/jiio/mediaLibImage;
J com.sun.media.imageioimpl.plugins.clib.CLibImageReader.read(ILjavax/imageio/
ImageReadParam;)Ljava/awt/image/BufferedImage;
J ImageTest$ImageRunnable.run()V
J java.util.concurrent.FutureTask$Sync.innerRun()V
J java.util.concurrent.FutureTask.run()V
J java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/Runnable;)V
J java.util.concurrent.ThreadPoolExecutor$Worker.run()V
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x39773400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=3192]
0x38ddb000 JavaThread "Process Image" daemon [_thread_blocked, id=2592]
0x38dda000 JavaThread "Process Image" daemon [_thread_blocked, id=3524]
0x38dd9400 JavaThread "Process Image" daemon [_thread_blocked, id=2816]
0x38dd6400 JavaThread "Process Image" daemon [_thread_blocked, id=3696]
0x38dd5400 JavaThread "Process Image" daemon [_thread_blocked, id=1236]
0x38dd3c00 JavaThread "Process Image" daemon [_thread_in_native, id=3860]
0x38dd2c00 JavaThread "Process Image" daemon [_thread_blocked, id=1260]
0x38dd2000 JavaThread "Process Image" daemon [_thread_blocked, id=2360]
0x38dd1000 JavaThread "Process Image" daemon [_thread_blocked, id=2752]
=>0x38dd0400 JavaThread "Process Image" daemon [_thread_in_native, id=1176]
0x38dcf000 JavaThread "Process Image" daemon [_thread_blocked, id=628]
0x38dcdc00 JavaThread "Process Image" daemon [_thread_blocked, id=3328]
0x38dccc00 JavaThread "Process Image" daemon [_thread_blocked, id=1152]
0x38dabc00 JavaThread "Process Image" daemon [_thread_blocked, id=452]
0x38daac00 JavaThread "Process Image" daemon [_thread_blocked, id=3120]
0x38dcb400 JavaThread "Process Image" daemon [_thread_blocked, id=1864]
0x38d8c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1348]
0x38d8b000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=692]
0x38d86800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3844]
0x38d85c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3200]
0x38d76800 JavaThread "Finalizer" daemon [_thread_blocked, id=4048]
0x38d72400 JavaThread "Reference Handler" daemon [_thread_blocked, id=1412]
0x002a6000 JavaThread "main" [_thread_blocked, id=4004]

Other Threads:
0x38d6f000 VMThread [id=3312]
0x38d8e000 WatcherThread [id=2860]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x002a4c38/0x00000714] Threads_lock - owner thread: 0x38d6f000
[0x002a4dd8/0x000006d4] Heap_lock - owner thread: 0x38daac00

Heap
def new generation total 1792K, used 86K [0x02990000, 0x02b80000, 0x06710000)
eden space 1600K, 0% used [0x02990000, 0x02990000, 0x02b20000)
from space 192K, 44% used [0x02b50000, 0x02b65948, 0x02b80000)
to space 192K, 0% used [0x02b20000, 0x02b20000, 0x02b50000)
tenured generation total 23516K, used 20718K [0x06710000, 0x07e07000,
0x34990000)
the space 23516K, 88% used [0x06710000, 0x07b4bb88, 0x069d6e00, 0x07e07000)
compacting perm gen total 12288K, used 3896K [0x34990000, 0x35590000,
0x38990000)
the space 12288K, 31% used [0x34990000, 0x34d5e018, 0x34bf0600, 0x35590000)
No shared spaces configured.

Dynamic libraries:
0x00400000 - 0x00423000 c:\java\jdk16\bin\java.exe
0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c8f5000 C:\WINDOWS\system32\kernel32.dll
0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll
0x7c340000 - 0x7c396000 c:\java\jdk16\jre\bin\msvcr71.dll
0x6d7c0000 - 0x6da07000 c:\java\jdk16\jre\bin\client\jvm.dll
0x77d40000 - 0x77dd0000 C:\WINDOWS\system32\USER32.dll
0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll
0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll
0x6d310000 - 0x6d318000 c:\java\jdk16\jre\bin\hpi.dll
0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL
0x6d770000 - 0x6d77c000 c:\java\jdk16\jre\bin\verify.dll
0x6d3b0000 - 0x6d3cf000 c:\java\jdk16\jre\bin\java.dll
0x6d7b0000 - 0x6d7bf000 c:\java\jdk16\jre\bin\zip.dll
0x6d1f0000 - 0x6d21f000 C:\java\jdk16\jre\bin\cmm.dll
0x6d450000 - 0x6d474000 C:\java\jdk16\jre\bin\jpeg.dll
0x003f0000 - 0x003fb000 C:\java\jdk16\jre\bin\clib_jiio_util.dll
0x39890000 - 0x3999c000 C:\java\jdk16\jre\bin\clib_jiio_sse2.dll
0x6d000000 - 0x6d1c3000 C:\java\jdk16\jre\bin\awt.dll
0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV
0x77c10000 - 0x77c68000 C:\WINDOWS\system32\msvcrt.dll
0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.dll
0x774e0000 - 0x7761d000 C:\WINDOWS\system32\ole32.dll

VM Arguments:
jvm_args: -Xmx800m -Dcom.sun.media.imageio.disableCodecLib=false
java_command: ImageTest D:_media\Pictures\ByHardware\other 100
Launcher Type: SUN_STANDARD

Environment Variables:
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 43 Stepping 1, AuthenticAMD

--------------- S Y S T E M ---------------

OS: Windows XP Build 2600 Service Pack 2

CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, mmxext, 3dnowext,
3dnow, ht

Memory: 4k page, physical 2095528k(1374224k free), swap 4194303k(4194303k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-b105) for windows-x86, built on Nov
29 2006 00:48:48 by "java_re" with unknown MS VC++:1310

------
System
------
Windows XP, 2GB ram, AMD Athlon64 X2 4200 dual-core CPU, Java 1.6, latest
imageio daily build (20070424).



gerardkoppelaar added a comment - 24/Apr/07 08:44 AM

Created an attachment (id=77)
file containing a test app that scans for images and then loads them randomly using multiple threads


jxc added a comment - 24/Apr/07 04:26 PM

Reassign to jxc.


jxc added a comment - 24/Apr/07 04:35 PM

I haven't been able to reproduce a JVM crash with the attached
test program on a Windows XP box with single CPU. I do see
some memory leaks on both Windows XP and Solaris/SPARC. On
Windows, the test program caused a lot of paging. On Solaris,
it caused OutOfMemory exceptions.


gerardkoppelaar added a comment - 26/Apr/07 04:44 AM

Maybe the problem is not as generic as I thought and depends on the type of the
images?

1. I will try to create a small set of images which are known to create the
problem here, so it can be included in the test and we all can use the same
images.
2. I will try to reproduce the problem on an other dual-core system.
3. I will try to reproduce the problem on a single-core system (might take some
time, I don't think we have that many singe-core systems with SSE2 support in
the office, I might have to run some tests at home).

P.S. While testing, I encountered a lot of other VM crashes originating in the
imagelib DLLs, all caused by the native code running out of memory/swap space
when trying to load a large image (which of course can occur but should NOT
crash the VM). Is it worth reporting these as a new defect?


gerardkoppelaar added a comment - 26/Apr/07 07:43 AM

Created an attachment (id=78)
Updated test app with two small images that crash the vm


gerardkoppelaar added a comment - 26/Apr/07 07:55 AM

1. Included an updated test app (threads reduced from 16 to 2 to reduce memory
usage), and INCLUDED a subdirectory with TWO SMALL JPG FILES that seem to be
enough crash the vm.
Running the given app for a few seconds to a few minutes seems to usually be
enough to produce the crash; there seem to be only two different frames where
the crashes occur:

Mostly:

  1. Problematic frame:
  2. C [clib_jiio_sse2.dll+0xaff2c]

Sometimes:

  1. Problematic frame:
  2. C [clib_jiio_sse2.dll+0xc32fb]

, is that of any help?

Also see all the error logs contained in the zip.

2. We REPRODUCED the crash on TWO OTHER DUAL-CORE systems (both AMD Athlon64-
X2, different speeds and steppings though).

3. We REPRODUCED the crash on ONE SINGLE_CORE system (AMD Athlon-64 3000+), so
the problem seems not to be limited to multi-core cpus.

Unfortunately we don't have an Intel system capable of SSE2, so we cannot
confirm if the crashes also occur on Intel cpu's.

If you need me to run other tests or use a different sse2.dll, please let me
know.


jxc added a comment - 26/Apr/07 12:04 PM

Thanks very much for providing the images and more info about the crashes.
I was still not able to reproduce the problem with the updated test case.
However, with the provided test2.jpg and using a simple test program like
the following,

public ImageIOTest(String fileName) {
InputStream imageStream =
getClass().getClassLoader().getResourceAsStream(fileName);

try { BufferedImage image = ImageIO.read(imageStream); } catch (Exception e) { e.printStackTrace(); }
}

I got a JVM crash at [clib_jiio_sse2.dll+0xaff2c].

This is the same place as that of the crash reported in issue 115:
https://jai-imageio-core.dev.java.net/issues/show_bug.cgi?id=115
which I am able to reproduce.

Yet I have not been able to reproduce the crash at
[clib_jiio_sse2.dll+0xc32fb].

A temporary workaround would be renaming clib_jiio_sse2.dll to
something else so that clib_jiio.dll be used.


jxc added a comment - 26/Apr/07 01:41 PM

Forgot to answer this question:
> P.S. While testing, I encountered a lot of other VM crashes originating in the
> imagelib DLLs, all caused by the native code running out of memory/swap space
> when trying to load a large image (which of course can occur but should NOT
> crash the VM). Is it worth reporting these as a new defect?

I haven't seen JVM crashes like that. Instead, I saw some exception like
"can not decode" after the OutOfMemoryError. Did the JVM crash at the same
place(s)? If yes, then no need to file a new issue. If not, then a new issue
might help us tracking.


gerardkoppelaar added a comment - 02/May/07 04:25 AM

Created an attachment (id=79)
image and dumps for error at [clib_jiio_sse2.dll+0xc32fb]


gerardkoppelaar added a comment - 02/May/07 04:36 AM

I attached a test image that can be used to crash the VM at
[clib_jiio_sse2.dll+0xc32fb].
Usually, on my test system it takes only a few minutes (a few thousand loads)
continuously loading the image for the crash to occur.

Note: I updated my JVM to 1.6.0_01.


jxc added a comment - 02/May/07 06:01 PM

Thanks for providing another image. But so far I haven't been able to
reproduce the JVM crash with this image.


gerardkoppelaar added a comment - 12/Jun/07 10:13 AM

Created an attachment (id=83)
An other file that often generates the 0xc32fb crash here