JDK-6415680 : (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-04-20
  • Updated: 2017-12-01
  • Resolved: 2017-11-15
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.
JDK 10
10 b34Fixed
Related Reports
Duplicate :  
Relates :  
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)

Windows XP Professional x64 Edition

# An unexpected error has been detected by HotSpot Virtual Machine:
#  EXCEPTION_IN_PAGE_ERROR (0xc0000006) at pc=0x6d7f3d0c, pid=1756, tid=2180
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x113d0c]

Stepping through the code (as far as I could) this got thrown in java.nio.DirectByteBuffer get() method while calling unsafe.getByte():

public byte get() {
   return ((unsafe.getByte(ix(nextGetIndex()))));



See source code for an executable test case

buffer.get() should stick some bytes into the byte array file but I get an EXCEPTION_IN_PAGE_ERROR instead
# An unexpected error has been detected by HotSpot Virtual Machine:
#  EXCEPTION_IN_PAGE_ERROR (0xc0000006) at pc=0x6db22eef, pid=332, tid=1352
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x2a2eef]

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

Current thread (0x00036030):  JavaThread "main" [_thread_in_vm, id=1352]

siginfo: ExceptionCode=0xc0000006, ExceptionInformation=0x00000000 0x01c30000 0xc0000309

EAX=0x00036030, EBX=0x03dfbcf0, ECX=0x00000002, EDX=0x01c30000
ESP=0x0016fa2c, EBP=0x0016fa38, ESI=0x00036030, EDI=0x00036030
EIP=0x6db22eef, EFLAGS=0x00010246

  Top of Stack: (sp=0x0016fa2c)
0x0016fa2c:   00036030 03dfbcf0 03dfbcf0 0016fa6c
0x0016fa3c:   01d6864c 000360f0 0016fa84 01c30000
0x0016fa4c:   00000000 0016fa50 00000000 0016fa84
0x0016fa5c:   03dfdd60 00000000 03dfbcf0 0016fa7c
0x0016fa6c:   0016faa4 01d62aeb 00000000 01d664f1
0x0016fa7c:   01c30000 00000000 244832c0 0016fa88
0x0016fa8c:   03ee74b3 0016faac 03eea108 00000000
0x0016fa9c:   03ee74c0 0016faac 0016facc 01d62aeb

Instructions: (pc=0x6db22eef)
0x6db22edf:   e1 b3 6d 8b 55 10 c7 80 04 01 00 00 01 00 00 00
0x6db22eef:   8a 0a c7 80 04 01 00 00 00 00 00 00 8b 7e 2c 88

Stack: [0x00130000,0x00170000),  sp=0x0016fa2c,  free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x2a2eef]
j  sun.misc.Unsafe.getByte(J)B+0
j  java.nio.DirectByteBuffer.get()B+11
j  net.borlin.dvd.util.FileCopyUtil.main([Ljava/lang/String;)V+76
v  ~StubRoutines::call_stub
V  [jvm.dll+0xf7040]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.misc.Unsafe.getByte(J)B+0
j  java.nio.DirectByteBuffer.get()B+11
j  net.borlin.dvd.util.FileCopyUtil.main([Ljava/lang/String;)V+76
v  ~StubRoutines::call_stub

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

Java Threads: ( => current thread )
  0x2814a060 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2084]
  0x28148cb8 JavaThread "CompilerThread1" daemon [_thread_blocked, id=1368]
  0x28147e48 JavaThread "CompilerThread0" daemon [_thread_blocked, id=2668]
  0x28146f10 JavaThread "AdapterThread" daemon [_thread_blocked, id=452]
  0x28146268 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2964]
  0x01d5ce90 JavaThread "Finalizer" daemon [_thread_blocked, id=2200]
  0x01d5ca00 JavaThread "Reference Handler" daemon [_thread_blocked, id=1400]
=>0x00036030 JavaThread "main" [_thread_in_vm, id=1352]

Other Threads:
  0x01d5a860 VMThread [id=1068]
  0x28146180 WatcherThread [id=1736]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

 PSYoungGen      total 3584K, used 322K [0x24480000, 0x24880000, 0x27d60000)
  eden space 3072K, 10% used [0x24480000,0x244d0b30,0x24780000)
  from space 512K, 0% used [0x24800000,0x24800000,0x24880000)
  to   space 512K, 0% used [0x24780000,0x24780000,0x24800000)
 PSOldGen        total 29184K, used 0K [0x07d60000, 0x099e0000, 0x24480000)
  object space 29184K, 0% used [0x07d60000,0x07d60000,0x099e0000)
 PSPermGen       total 16384K, used 1581K [0x03d60000, 0x04d60000, 0x07d60000)
  object space 16384K, 9% used [0x03d60000,0x03eeb688,0x04d60000)

Dynamic libraries:
0x00400000 - 0x0040c000 	C:\Program Files (x86)\Java\jdk1.5.0_06\bin\java.exe
0x7d600000 - 0x7d6f0000 	C:\WINDOWS\system32\ntdll.dll
0x7d4c0000 - 0x7d5f0000 	C:\WINDOWS\syswow64\kernel32.dll
0x77f50000 - 0x77fec000 	C:\WINDOWS\syswow64\ADVAPI32.dll
0x7da20000 - 0x7db00000 	C:\WINDOWS\syswow64\RPCRT4.dll
0x77ba0000 - 0x77bfa000 	C:\WINDOWS\syswow64\MSVCRT.dll
0x6d880000 - 0x6dc31000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\server\jvm.dll
0x7d930000 - 0x7da00000 	C:\WINDOWS\syswow64\USER32.dll
0x7d800000 - 0x7d890000 	C:\WINDOWS\syswow64\GDI32.dll
0x76aa0000 - 0x76acd000 	C:\WINDOWS\system32\WINMM.dll
0x6d2f0000 - 0x6d2f8000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\hpi.dll
0x76b70000 - 0x76b7b000 	C:\WINDOWS\system32\PSAPI.DLL
0x6d6b0000 - 0x6d6bc000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\verify.dll
0x6d370000 - 0x6d38d000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\java.dll
0x6d6d0000 - 0x6d6df000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\zip.dll
0x6d530000 - 0x6d543000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\net.dll
0x71c00000 - 0x71c17000 	C:\WINDOWS\system32\WS2_32.dll
0x71bf0000 - 0x71bf8000 	C:\WINDOWS\system32\WS2HELP.dll
0x6d550000 - 0x6d559000 	C:\Program Files (x86)\Java\jdk1.5.0_06\jre\bin\nio.dll

VM Arguments:
java_command: net.borlin.dvd.util.FileCopyUtil e:\video_ts\video_ts.vob C:\Documents and Settings\Phil\My Documents\movies\Short Circuit\video_ts.vob
Launcher Type: SUN_STANDARD

Environment Variables:
PROCESSOR_IDENTIFIER=AMD64 Family 15 Model 43 Stepping 1, AuthenticAMD

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

OS: Windows Server 2003 family Build 3790 Service Pack 1

CPU:total 2 family 47, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 2096512k(1474812k free), swap 4059224k(3561804k free)

vm_info: Java HotSpot(TM) Server VM (1.5.0_06-b05) for windows-x86, built on Nov 10 2005 10:53:00 by "java_re" with MS VC++ 6.0

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
A simple class that will reproduce this is:
usage: java FileCopyUtil <filename>

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.channels.FileChannel.MapMode;

public class FileCopyUtil {

	public FileCopyUtil() {
	 * @param args
	public static void main(String[] args) {
		File src = new File(args[0]);
		try {
			byte[] file = new byte[(int) src.length()];
			FileChannel channel = new FileInputStream(src).getChannel();
			MappedByteBuffer buffer = channel.map(MapMode.READ_ONLY, 0, src.length());
		} catch (FileNotFoundException e) {
		} catch (IOException e) {

---------- END SOURCE ----------

Use InputStreams into of channels

as per Mikael's comment JDK-8154592 "The only operations which can access these regions (currently) are jdk.internal.misc.Unsafe (or sun.misc), which read and write single values in memory." https://bugs.openjdk.java.net/browse/JDK-8154592 and guarding implementation in Unsafe matches the descriptions, while i see jdk MappedBuffer code access to larger chunks and are prone to page error/ sigbus. so these crashes are expected?

i.e: public ByteBuffer get(byte[] dst, int offset, int length) { if (((long)length << 0) > Bits.JNI_COPY_TO_ARRAY_THRESHOLD) { checkBounds(offset, length, dst.length); int pos = position(); int lim = limit(); assert (pos <= lim); int rem = (pos <= lim ? lim - pos : 0); if (length > rem) throw new BufferUnderflowException(); long dstOffset = arrayBaseOffset + ((long)offset << 0); unsafe.copyMemory(null, ix(pos), dst, dstOffset, (long)length << 0); position(pos + length); } else { super.get(dst, offset, length); } return this; copyMemory is not guarded, an invalid memory here would crash..

i see there are many mapped memory access through unsafe not guarded, and this issue should be there in all platforms. JDK-4454115 doesn't seems to solve the issue completely?

Hi Vladimir [~kvn], i was referring to this bug. question is why is this not being fixed for such a long time, bug is easily reproducible, and i am just trying to gather history of fix attempt, if any!

oh ok, i missed that decision, Thanks for pointing that., changing back to hotspot.

Why has this been moved back to core-libs? I thought we decided to do the equivalent of JDK-4454115 on Windows. This will means changes to os_windows.cpp, I don't think we can do anything in the MBB implementation.

Reading from or writing to a file view of a file other than the page file can cause an EXCEPTION_IN_PAGE_ERROR exception. For example, accessing a mapped file that resides on a remote server can generate an exception if the connection to the server is lost. Exceptions can also occur because of a full disk, an underlying device failure, or a memory allocation failure. When writing to a file view, exceptions can also occur because the file is shared and a different process has locked a byte range. To guard against exceptions due to input and output (I/O) errors, all attempts to access memory mapped files should be wrapped in structured exception handlers. When you receive EXCEPTION_IN_PAGE_ERROR in your __except filter, make sure that the address is within the mapping you are currently accessing. If so, recover or fail gracefully; otherwise, do not handle the exception. issue is observed in Xint mode too, moving it to core-libs for appropriate resolution

9-defer-SQE-ok: issue wasn't introduced in 9, happens in specific cases such as windows version reading encrypted dvd

9-defer-request: P3, Old bug (issue was filed in 2006).

Just an FYI: I /almost/ have the changes working across all the different platforms now, but I still need to investigate some issues on Solaris. That said, AFAICT this works slightly differently on Windows than on the posix/unix platforms. In particular it seems that Windows doesn't allow truncation of files which are memory mapped (at least not truncation past the end offset of the mapping(s)), so the changes I'm making may or may not help address the problem described in this issue.

Sure, Zoltan!

Hi Jamsheed, can you please take a look? Thank you! Zoltan

[~vlivanov]: Is there a different bug that tracks the 8u65 failure?

Was recently reported against 8u65 (JDK-6415680).

ILW=Crash;read from dvds w/ copy protection;rewrite java code as the reporter advised: Use InputStreams into of channels =HLM=>P3

Does this still reproduce?

EVALUATION From the comments: This looks like the windows version of the bug 4454115 which doesn't appear to have been fixed on windows. The windows exception handler probably needs the equivalent fix, using EXCEPTION_IN_PAGE_ERROR instead of SIGBUS/BUS_OBJERR.

EVALUATION -- The submitter has observed that this problem only arises with encrypted file systems and copy-protected DVDs. One possible solution we will examine for Dolphin is to have the FileChannel.map method throw an exception for this case. We would be interested in hearing from others than have experienced this exception when accessing a MappedByteBuffer. If you can demonstrate this problem please add a JDC comment with the details.

SUGGESTED FIX If we can establish this issue always occurs with encrypted files then one possible "solution" is to examine the file attributes prior to mapping. If FILE_ATTRIBUTE_ENCRYPTED is set then we can have the map method throw an IOException with a suitable message.

EVALUATION -- We haven't heard any more from submitter but we suspect this is a device or media failure provoking this exception. As noted, we don't currently handle this exception gracefully and we suspect it is very rare (this is the first bug report on this issue). We will examine it further in Dolphin - the tricky bit is that the specification doesn't allow for the get/put methods to fail with anything other than the currently specified exceptions.

EVALUATION Reading (or writing) from a file view is documented to cause the EXCEPTION_IN_PAGE_ERROR exception in error situations. We don't currently handle this and don't have any (specified) way for the get method or other operations on the MappedByteBuffer to fail. Examples that are documented on the Microsoft site include device failure, disk full, memory allocation failure, and the lost of a connection to a remote file system. In this example, it appears that the failure occurs with a mapping to a file on the E: drive. It would be useful to know if this is mapped drive or if it is a local drive (perhaps it's a CD or DVD).