JDK 9 RFR of 8168628: (ch) JVM Crash in : ~StubRoutines::jshort_disjoint_arraycopy

Brian Burkhalter brian.burkhalter at oracle.com
Fri Dec 2 21:33:09 UTC 2016


On Dec 2, 2016, at 4:43 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 02/12/2016 02:13, Brian Burkhalter wrote:
> 
>> Please review at your convenience:
>> 
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8168628
>> Patch:	http://cr.openjdk.java.net/~bpb/8168628/webrev.00/
>> 
>> The FileChannel.map() method extends the size of the file being mapped when it is not already sufficiently large. On Unix, file size extension is implemented via the ftruncate() function. On Linux, this function does not actually allocate any blocks for the file when the new size is larger than the existing size. This may cause problems when the file is memory-mapped. This might occur proximately because map() may be invoked from multiple, different threads wherein one thread reduces the size of a file previously mapped at a larger size by another thread. The eventual result is a SIGBUS.
>> 
>> This patch addresses the problem by using fallocate() on Linux when the requested size exceeds the allocated size, and by synchronizing on positionLock in the section in FileChannelImpl.map() where the file is extended. Note that the same crash is observed on OS X without the addition of this synchronization.
>> 
> I've read through your exchange with Robbin in JIRA and I think this is okay. It was an oversight that map didn't synchronize on positionLock when extending the size and I think you'll need to extend the scope to include the mmap itself, otherwise another thread can truncate it between the resize + mmap).

Revised patch: http://cr.openjdk.java.net/~bpb/8168628/webrev.01/

The differences with respect to webrev.00 are:

1) Enlarge the scope of the synchronized block to include map0().

2) Add the changes to src/java.base/unix/native/libjava/io_util_md.c

I am investigating collapsing the tests attached to the issue into a single test which is *not* run automatically.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161202/69931ccf/attachment-0001.html>


More information about the nio-dev mailing list