United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6244515 : Unsafe operations that access invalid memory are not handled gracefully

Details
Type:
Bug
Submit Date:
2005-03-22
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2005-10-06
Component:
hotspot
OS:
solaris_8
Sub-Component:
runtime
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:

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

Sub Tasks

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



Hardware and Software, Engineered to Work Together