Bug: MemorySegment bounds check doesn't work for some values and allows segmentation fault

[Maurizio Cimadamore]

On 30/04/2021 13:57, Marcel Käufler wrote:
> Hi Maurizio,
>
> with the SmallSegments=false flag I get an IndexOutOfBoundsException 
> as it should be:
>
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Out of 
> bound access on segment MemorySegment{ id=0xa886412 limit: 2147479552 
> }; new offset = 8223372036854705800; new length = 8

Yeah - it seems like the optimized 
AbstractMemorySegmentImpl::checkBoundsSmall doesn't check for overflow.

I'll see if adding that check will throw optimizations out of the 
window; if not, I'll fix this. If yes, I think it's better to leave as 
is, and wait for the "real" fix (which is to remove all such hacks and 
just enable long loop optimizations - we're pretty close there).

Maurizio

>
>
> Best Regards,
> Marcel
>
>
> On 30.04.21 14:05, Maurizio Cimadamore wrote:
>> Hi,
>> thanks for the report - I suspect this is caused by the long vs. int 
>> workaround we have scattered all over the place.
>>
>> Can you try running with 
>> "-Djdk.incubator.foreign.SmallSegments=false" and see what happens?
>>
>> Cheers
>> Maurizio
>>
>> On 30/04/2021 12:45, Marcel Käufler wrote:
>>> Hi,
>>>
>>> I've encountered a bug with the MemorySegment bounds check. For some 
>>> values, instead of throwing and IndexOutOfBoundsException, the 
>>> access goes through and causes a segmentation fault. I didn't dig 
>>> into it but I expect some kind of overflow / casting error that 
>>> makes the address appear to be in a valid range.
>>>
>>> Tested with both the JDK 16 release and the current panama main branch.
>>>
>>> To reproduce:
>>>
>>> import jdk.incubator.foreign.MemoryAccess;
>>> import jdk.incubator.foreign.MemorySegment;
>>> import jdk.incubator.foreign.ResourceScope;
>>>
>>> public class SIGSEGV {
>>>     public static void main(String[] args) {
>>>         MemorySegment memorySegment = 
>>> MemorySegment.allocateNative(2147479552, ResourceScope.globalScope());
>>>         MemoryAccess.getLongAtOffset(memorySegment, 
>>> 8223372036854705800L);
>>>     }
>>> }
>>>
>>>
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGSEGV (0xb) at pc=0x00007f345fc19053, pid=224993, tid=224996
>>> #
>>> # JRE version: OpenJDK Runtime Environment (17.0) (build 
>>> 17-internal+0-adhoc..panama-foreign)
>>> # Java VM: OpenJDK 64-Bit Server VM 
>>> (17-internal+0-adhoc..panama-foreign, mixed mode, sharing, tiered, 
>>> compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>>> # Problematic frame:
>>> # V  [libjvm.so+0xf0a053]  Unsafe_GetLong+0x133
>>> #
>>> # Core dump will be written. Default location: Core dumps may be 
>>> processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c 
>>> %h" (or dumping to /home/marcel/IdeaProjects/BoundsCheck/core.224993)
>>> #
>>> # An error report file with more information is saved as:
>>> # /home/marcel/IdeaProjects/BoundsCheck/hs_err_pid224993.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> # 
>>> https://urldefense.com/v3/__https://bugreport.java.com/bugreport/crash.jsp__;!!GqivPVa7Brio!MUuIDtpQbzxeIlw90rUObOEf0qyv1gcu8_KacA-pW1Rdrj2WRVUxZ3tJ4N8s09w92C8ZnkI$ 
>>> #
>>>
>>> Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
>>>
>>>
>>> Best Regards,
>>> Marcel
>>>
>