Java 17 bug (?) on Windows with MemorySegment.asSlice and offset =

[Maurizio Cimadamore]

I have spotted something...

The code that creates a mapped buffer is like this:

```
return Util.newMappedByteBufferR((int)unmapper.cap,
                     unmapper.address + unmapper.pagePosition,
                     unmapper.fd,
                     unmapper, isSync);
```

While the code that creates the mapped segment is like this:

```
AbstractMemorySegmentImpl segment = new 
MappedMemorySegmentImpl(unmapper.address(), unmapper, size,
                     modes, session);
```

While the two are similar, there are some differences:

* the BB version is using unmapper.cap for the size, while the segment 
version is just passing the size - on further inspection, this 
difference seems benign, as unmapper.cap seems to be always set to the 
user specified byte size
* the BB address is set to unmapper.address + pagePosition - now this is 
an actual difference between the two snippets - the memory segment 
version ignores pagePosition.

The second difference seems like a bug - that said, it should only 
manifest when mapping a file with a non-zero offset, as pagePosition is 
computed as follows:

```
pagePosition = (int)(position % allocationGranularity);
```

(where `position` is really the memory mapped offset). That is, if the 
specified offset is zero, the base address of the mapped segment should 
always be page-aligned.

So, I don't think this issue, alone, (while a bug) is enough to explain 
what's going on.

Maurizio


On 12/05/2022 10:32, Maurizio Cimadamore wrote:
> Uhm... this seems worse.
>
> Something seems to point at the spatial bounds of the segment not 
> being set correctly.
>
> Maurizio
>
> On 12/05/2022 09:45, erel at eth.gl wrote:
>> (sorry for the frequent messages)
>>
>>
>> In the previous example the exception was thrown from the “force” 
>> call. A low level error happens with similar code:
>>
>> long offset = 3704800000L;
>>
>>              ByteBuffer bb = ByteBuffer.allocateDirect(100000);
>>
>>              MemorySegment mbb = MemorySegment.ofByteBuffer(bb);
>>
>>              while (true) {
>>
>>                    System.out.println("offset: " + offset);
>>
>>                    MemorySegment target = 
>> mappedMemorySegment.asSlice(offset, 100000);
>>
>>                    offset = offset + 100000;
>>
>>                    target.copyFrom(mbb);
>>
>>              }
>>
>>
>> Output:
>>
>>
>> WARNING: Using incubator modules: jdk.incubator.foreign
>>
>> 64
>>
>> amd64
>>
>> 17.0.3.1
>>
>> byteSize: 8000000000
>>
>> offset: 3704800000
>>
>> offset: 3704900000
>>
>> offset: 3705000000
>>
>> #
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>>
>> #
>>
>> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000027a6c4f4176, 
>> pid=16060, tid=2208
>>
>> #
>>
>> # JRE version: Java(TM) SE Runtime Environment (17.0.3.1+2) (build 
>> 17.0.3.1+2-LTS-6)
>>
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.3.1+2-LTS-6, mixed 
>> mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, 
>> windows-amd64)
>>
>> # Problematic frame:
>>
>> # v  ~StubRoutines::jlong_disjoint_arraycopy
>>
>> #
>>
>> # No core dump will be written. Minidumps are not enabled by default 
>> on client versions of Windows
>>
>> #
>>
>> # An error report file with more information is saved as:
>>
>> # …\hs_err_pid16060.log
>>
>> #
>>
>> # If you would like to submit a bug report, please visit:
>>
>> #   https://bugreport.java.com/bugreport/crash.jsp
>>
>> #
>>
>>