RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR
david.holmes at oracle.com
Tue Nov 14 21:18:18 UTC 2017
On 15/11/2017 7:11 AM, jamsheed wrote:
> Hi Dean,
> revised webrev:
> i agree to the comment that it is potentially unsafe to assume the
> implementation, and count can be in autoincrement mode. so with this bug
> i would like to deal with only the single value access error handling.
> revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/
Okay so now this just brings to windows what currently exists on the
other platforms - right?
Seems reasonable for now. Longer term we should look at the bulk
> Best regards,
> On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote:
>> Adding runtime alias...
>> comments inlined below.
>> On 11/13/17 9:10 PM, jamsheed wrote:
>>> Hi, request for review, jbs:
>>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev:
>>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1)
>>> changes equivalent to JDK-4454115 is done for windows.
>> It looks like "nm" can be uninitialized if "in_java" is false.
>>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0,
>>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0.
>> Can you narrow the scope of the unsafe access using something like
>> GuardUnsafeAccess, instead of marking the whole function as doing
>> unsafe access?
>> There are some risks with trying to abort a copy function.
>> First, won't we get multiple exceptions until we finally hit the end
>> of the range? What if the bad range is very large?
>> Second, what if the loop is using auto-increment instructions?
>> Skipping to the next instruction would mean we loop forever if the
>> increment never happens.
>> I think if we are going to safely abort copy functions then we need to
>> register them as a kind of CodeBlob that has a special abort entry
>> point or exception handler we can redirect to, or maybe pop the whole
>> frame and return.
>> Is there really a problem with these copy functions? I'm wondering
>> why Mikael did not identify these as a problem in 8154592.
>>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed
>>> thread->thread_state() == _thread_in_vm checks from signal handler
>> How about adding a check for _thread_in_native instead of removing the
>> check entirely?
>>> Best regards, Jamsheed
More information about the hotspot-compiler-dev