[10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR

[David Holmes]

On 15/11/2017 7:11 AM, jamsheed wrote:
> Hi Dean,
> 
> revised webrev:
> 
> http://cr.openjdk.java.net/~jcm/6415680/webrev.01/
> 
> 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 
operation problem.

Thanks,
David

> Best regards,
> 
> Jamsheed
> 
> 
> 
> 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?
>>
>> dl
>>
>>> Best regards, Jamsheed
>>>
>>
>