JDK-6244515 : Unsafe operations that access invalid memory are not handled gracefully
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P2
  • Affected Version: 1.4.2
  • OS: solaris_8
  • CPU: sparc
  • Submit Date: 2005-03-22
  • Updated Date: 2012-10-08
  • Resolved Date: 2005-10-06
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 6
6 b55Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The specification of java.nio.MappedByteBuffer says:

    All or part of a mapped byte buffer may become inaccessible at any time,
    for example if the mapped file is truncated.  An attempt to access an
    inaccessible region of a mapped byte buffer will not change the buffer's
    content and will cause an unspecified exception to be thrown either at the
    time of the access or at some later time.  ...

This behavior was intended to be implemented in 1.40-beta2 by RFEs 4454110
(runtime), 4454113 (c1), and 4454115 (c2).  The implementation is incomplete on
solaris-sparc and totally absent on linux-i586; I haven't checked any other
os/arch combinations.

With 1.4.0-beta2 on solaris-sparc, the following program crashes the VM with
-Xint but throws the expected error ("java.lang.InternalError: a fault occurred
in an unsafe memory access operation") with -Xcomp -client and -Xcomp -server.
The same behavior was observed with 1.4.0-beta3, 1.4.0-fcs, 1.4.1, 1.4.2,
1.5.0, and 1.6.0-b28.

With 1.4.0-beta2 on linux-i586, the following program crashes the VM with
-Xint, with -Xcomp -client, and with -Xcomp -server.  The same behavior was
observed with 1.4.0-beta3, 1.4.0-fcs, 1.4.1, 1.4.2, 1.5.0, and 1.6.0-b28.

Note that the program must be edited slightly in order to be compiled with
1.4.0-beta2 due to later API changes.  It must also be recompiled from beta3
to FCS.  For convenience I've attached a tarball containing class files for
each version.

----
import java.io.*;
import java.nio.*;
import java.nio.channels.*;


public class Truncate {

    private static final int SIZE = 1 << 16;

    public static void main(String[] args) throws Exception {
	FileChannel fc = new RandomAccessFile("/tmp/z", "rw").getChannel();
	fc.position(SIZE);
	fc.write(ByteBuffer.allocate(1));
	MappedByteBuffer bb
	    // Uncomment this line for 1.4.0 beta2
	    //= fc.map(FileChannel.MAP_RW, 0, SIZE);
	    // Uncomment this line for 1.4.0 beta3 or later
	    = fc.map(FileChannel.MapMode.READ_WRITE, 0, SIZE);

	bb.put((byte)1).put((byte)2).put((byte)3).put((byte)4);
	fc.truncate(0);
	bb.put((byte)5);
    }

}
----

Ideally this bug should be fixed in 1.4.2_XX, 5.0uX, and Mustang.

###@###.### 2005-03-22 22:43:01 GMT
Additional note: This bug only affects Unix systems (i.e., Solaris and Linux).
Windows does not allow a memory-mapped file to be truncated, so it's impossible
to observe this behavior.

Comments
EVALUATION Fixed 6244515: Unsafe operations that access invalid memory are not handled gracefully This was partially fixed in solaris, but the code for get/set native<type> was setting a field in thread which is read by the exception handler to determine whether to crash or throw an exception. The field in thread wasn't volatile, which made the -Xint case fail when the compiled code cases passed. t->set_doing_unsafe_access(true); \ (optimized away) jbyte x = *(signed_char*)p; \ t->set_doing_unsafe_access(false); \ The code is also implemented in linux and doesn't apply to windows. Stub routines were moved to platform independant places. Fix verified (y/n): y Verified by: Truncate.java (added to regression test suite) Other testing: runThese -jck -client x86 linux nsk -client x86 linux runThese -jck -server amd64 linux nsk -server amd64 linux nsk -server/-client solaris/sparc Webrev: http://jruntime.east/~coleenp/webrev/6244515_2 Reviewed by: dice, jrose, tom R, kbr Approved by: rt_baseline gatekeeper - low risk bug fix
2005-09-27

EVALUATION Fixing in -Xint solaris and linux. A bit stuck on windows.
2005-09-20