Segfault running ReflectionSpeedBenchmark

[nbhuiyan]

ReflectionSpeedBenchmark runs into a segfault 100% of the time. I have observed this failure in JDK18 running on x86-64 Linux, and it is possible that the failure happens on other platforms as well. The failure is reproducible using -Xint. This may be a result of a recent change as I have been running this test using an older build with no issues.

Unhandled exception
Type=Segmentation error vmState=0xffffffff
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007FE354344160 Handler2=00007FE34FA5CE30 InaccessibleAddress=00007FE300000008
RDI=00007FE300000000 RSI=00007FE300000020 RAX=00007FE300000000 RBX=00007FE300000020
RCX=0000000000000104 RDX=0000000000000000 R8=00007FE350090F08 R9=00007FE350092100
R10=00007FE350092140 R11=00007FE350000080 R12=00007FE354B55380 R13=00007FE300000000
R14=000000000000000F R15=00007FE350014800
RIP=00007FE34FA73A80 GS=0000 FS=0000 RSP=00007FE354BD6938
EFlags=0000000000010202 CS=0033 RBP=00007FE34FCA56A0 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=00007FE300000008
xmm0 dddddddddddddddd (f: 3722305024.000000, d: -1.456816e+144)
xmm1 7373616c432f676e (f: 1127180160.000000, d: 1.355073e+248)
xmm2 ffffffffffffffff (f: 4294967296.000000, d: -nan)
xmm3 00007fe3500000f0 (f: 1342177536.000000, d: 6.947268e-310)
xmm4 4040404040404040 (f: 1077952512.000000, d: 3.250196e+01)
xmm5 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm6 0000000000000002 (f: 2.000000, d: 9.881313e-324)
xmm7 00000000000000ff (f: 255.000000, d: 1.259867e-321)
xmm8 657275736e452b3a (f: 1850026752.000000, d: 4.787190e+180)
xmm9 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm10 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm11 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm12 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm13 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm14 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm15 0000000000000000 (f: 0.000000, d: 0.000000e+00)
Module=/root/builds/openj9-openjdk-jdk18/build/linux-x86_64-server-release/images/jdk/lib/default/libj9prt29.so
Module_base_address=00007FE34FA34000

Target=2_90_20220809_000000 (Linux 5.4.0-122-generic)
CPU=amd64 (8 logical CPUs) (0x1f1446000 RAM)

I have included the ReflectionSpeedBenchmark package I used for running the tests. To reproduce the failure, run path/to/java -Xint -jar target/benchmarks.jar. ReflectionSpeedBenchmark.tar.gz

[gacholio]

#14 <signal handler called>
#15 0x00007f0601207c94 in omrmem_get_footer_tag (headerEyeCatcherAddress=0x7f0500000000)
    at ../../omr/port/common/omrmemtag_checks.c:125
#16 0x00007f0601206eb9 in unwrapBlockAndCheckTags (portLibrary=0x7f0602129f00, 
    memoryPointer=0x7f0500000020) at ../../omr/port/common/omrmemtag.c:127
#17 0x00007f0601207282 in omrmem_free_memory (portLibrary=0x7f0602129f00, 
    memoryPointer=0x7f0500000020) at ../../omr/port/common/omrmemtag.c:205
#18 0x00007f060198dd4d in parseEnsureHashedOption (jvm=0x7f05fc019050, 
    option=0x7f05fc084d00 "java/lang/Class", isAdd=1) at jvminit.c:8267
#19 0x00007f060198de8d in parseEnsureHashedConfig (jvm=0x7f05fc019050, 
    options=0x7f05fc00de80 "java/lang/Class,java/lang/Thread", isAdd=1) at jvminit.c:8307
#20 0x00007f0601981ba2 in VMInitStages (vm=0x7f05fc019050, stage=6, reserved=0x0)
    at jvminit.c:2559
#21 0x00007f060198704d in runJ9VMDllMain (dllLoadInfo=0x7f05fc027568, 
    userDataTemp=0x7f060292b670) at jvminit.c:3947

[gacholio]

Reproduces with java -Xint -XX:+EnsureHashed:java/lang/Class -version

[gacholio]

This is almost certainly due to the ensure hash being done twice (once in the default option file, once on the command line).

[gacholio]

Crash is here: https://github.com/eclipse-openj9/openj9/blob/92da2c631ff02874fc260c82afa02ab73e22ea73/runtime/vm/jvminit.c#L8265-L8270

[gacholio]

I said when this code was introduced that it was too confusing - apparently I was right.

[gacholio]

Issue is the hash table entry being removed before the indirect used to free it. Fetching first fixes it, though a better solution would to simply not modify the table at all for duplicates.

[gacholio]

Marking this as high priority (for possible backport) as this is a likely (if not 100% guaranteed) crash on any application which forks a subprocess and passes along all the command line options.

[gacholio]

@pshipton

[pshipton]

Related to https://github.com/eclipse-openj9/openj9/pull/15444 which is not yet included in any OpenJ9 release (but is in IBM Java 8 22_03u1).