JDK-8255270 : java/foreign/TestMismatch.java still fails on 32-bit platforms
  • Type: Bug
  • Component: core-libs
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-10-22
  • Updated: 2020-10-22
  • Resolved: 2020-10-22
Related Reports
Duplicate :  
JDK-8254162 - Implementation of Foreign-Memory Access API (Third Incubator)
Relates :  
JDK-8253590 - java/foreign tests are still failing on x86_32 after foreign-memaccess integration
Sub Tasks
JDK-8255331 :  
Problemlist java/foreign/TestMismatch.java on 32-bit platforms until JDK-8254162 - Resolved
Description
$ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestMismatch.java

test TestMismatch.testLarge(): failure
java.lang.OutOfMemoryError: Unable to allocate 2147483660 bytes
	at java.base/jdk.internal.misc.Unsafe.allocateMemory(Unsafe.java:632)
	at jdk.incubator.foreign/jdk.internal.foreign.NativeMemorySegmentImpl.makeNativeSegment(NativeMemorySegmentImpl.java:91)
	at jdk.incubator.foreign/jdk.incubator.foreign.MemorySegment.allocateNative(MemorySegment.java:612)
	at jdk.incubator.foreign/jdk.incubator.foreign.MemorySegment.allocateNative(MemorySegment.java:559)
	at TestMismatch.testLarge(TestMismatch.java:114)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Comments
Ok, and since that hunk relies on MemoryLayouts.ADDRESS introduced in the same bulk change, we cannot really cherry-pick it. Closing as duplicate then.
22-10-2020
The test should be splitted out - this is already part of the current round of review (see https://git.openjdk.java.net/jdk/pull/548); this test is to specifically attempt to compute a memory region mismatch where the size of the region is bigger than an int, so it doesn't make sense in 32 bits. Here's the code proposed in that PR: @Test public void testLarge() { // skip if not on 64 bits if (MemoryLayouts.ADDRESS.byteSize() > 32) { try (var s1 = MemorySegment.allocateNative((long) Integer.MAX_VALUE + 10L); var s2 = MemorySegment.allocateNative((long) Integer.MAX_VALUE + 10L)) { assertEquals(s1.mismatch(s1), -1); assertEquals(s1.mismatch(s2), -1); assertEquals(s2.mismatch(s1), -1); testLargeAcrossMaxBoundary(s1, s2); testLargeMismatchAcrossMaxBoundary(s1, s2); } } }
22-10-2020
Maurizio, tell me if you want to split off testLarge testcase to 64-bit configs only. Otherwise, please suggest what else can be done.
22-10-2020
I tried to fix it as Maurizio did for other tests in JDK-8253590: diff --git a/test/jdk/java/foreign/TestMismatch.java b/test/jdk/java/foreign/TestMismatch.java index 5c361a82fe9..acc46de5244 100644 --- a/test/jdk/java/foreign/TestMismatch.java +++ b/test/jdk/java/foreign/TestMismatch.java @@ -23,7 +23,7 @@ /* * @test - * @run testng TestMismatch + * @run testng/othervm -Dforeign.restricted=permit TestMismatch */ import java.lang.invoke.VarHandle; @@ -111,8 +111,8 @@ public class TestMismatch { @Test public void testLarge() { - try (var s1 = MemorySegment.allocateNative((long)Integer.MAX_VALUE + 10L); - var s2 = MemorySegment.allocateNative((long)Integer.MAX_VALUE + 10L)) { + try (var s1 = MemorySegment.ofNativeRestricted(MemoryAddress.NULL, (long)Integer.MAX_VALUE + 10L, null, null, null); + var s2 = MemorySegment.ofNativeRestricted(MemoryAddress.NULL, (long)Integer.MAX_VALUE + 10L, null, null, null)) { assertEquals(s1.mismatch(s1), -1); assertEquals(s1.mismatch(s2), -1); assertEquals(s2.mismatch(s1), -1); ...but that would not work -- because we actually try to do stuff with that restricted segment, possibly corrupting memory. Thankfully it crashes in Unsafe_GetByte access at si_addr=0x0. Maybe this test should not be executed at 32 bits at all?
22-10-2020