Segmentation error during Java_java_lang_invoke_MethodHandleNatives_resolve call

[Wojciech-H]

Java -version output

openjdk version "17.0.13" 2024-10-15
IBM Semeru Runtime Open Edition 17.0.13.11 (build 17.0.13+11)
Eclipse OpenJ9 VM 17.0.13.11 (build openj9-0.48.0, JRE 17 Linux amd64-64-Bit Compressed References 20241015_886 (JIT enabled, AOT enabled)
OpenJ9 - 1d58314
OMR - d10a4d553
JCL - d17dd58f8d7 based on jdk-17.0.13+11)

Summary of problem

Segmentation error regularly occurs during execution of automated tests.
The error is triggered by Puma (Ruby on Rails development server) which runs on JRuby using IBM Semeru Runtime Open Edition 17.0.13.

Full log:

Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F939CCDCD60 Handler2=00007F939CC35750 InaccessibleAddress=00007F931B6FA074
RDI=00007F931B6FA074 RSI=00007F931AF6B074 RAX=0000000000000000 RBX=00007F93985F3230
RCX=00007F9307E21830 RDX=0000000000000020 R8=0000000000000001 R9=0000000000000000
R10=0000000000377B00 R11=00007F939802ABE0 R12=0000000000000000 R13=00007F9399F4DFD0
R14=00007F931AF6AB90 R15=00007F939D2384A0
RIP=00007F939D42C9F2 GS=0000 FS=0000 RSP=00007F931AF6AB08
EFlags=0000000000010246 CS=0033 RBP=00007F9399F4DFD0 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=00007F931B6FA074
xmm0=0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm1=6e616c2f6176616a (f: 1635148160.000000, d: 5.038250e+223)
xmm2=00007f9307e21830 (f: 132257840.000000, d: 6.930233e-310)
xmm3=ffffffffffffffff (f: 4294967296.000000, d: -nan)
xmm4=00000000043c60d0 (f: 71065808.000000, d: 3.511117e-316)
xmm5=0000003000000020 (f: 32.000000, d: 1.018558e-312)
xmm6=0000000003e24bf0 (f: 65162224.000000, d: 3.219442e-316)
xmm7=00000007fab5b910 (f: 4206213376.000000, d: 1.693212e-313)
xmm8=c004e474cd05101f (f: 3439661056.000000, d: -2.611551e+00)
xmm9=3f60624dd2f1a9fc (f: 3539053056.000000, d: 2.000000e-03)
xmm10=41cdb681a0000000 (f: 2684354560.000000, d: 9.970000e+08)
xmm11=ca62c1d6ca62c1d6 (f: 3395469824.000000, d: -2.193092e+50)
xmm12=0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm13=08090a0b0c0d0e0f (f: 202182160.000000, d: 5.924543e-270)
xmm14=0200000000000000 (f: 0.000000, d: 4.778310e-299)
xmm15=0000000000000000 (f: 0.000000, d: 0.000000e+00)
Module=/lib64/libc.so.6
Module_base_address=00007F939D2D3000
Target=2_90_20241015_886 (Linux 4.18.0-553.36.1.el8_10.x86_64)
CPU=amd64 (8 logical CPUs) (0x7c9025000 RAM)
----------- Stack Backtrace -----------
__memcmp_avx2_movbe+0x12 (0x00007F939D42C9F2 [libc.so.6+0x1599f2])
constraintHashEqualFn+0x2b (0x00007F939CE1258B [libj9vm29.so+0x17558b])
hashTableAddNodeInList+0x54 (0x00007F939CE07184 [libj9vm29.so+0x16a184])
registerClassLoadingConstraint+0xbe (0x00007F939CE1265E [libj9vm29.so+0x17565e])
j9bcv_checkClassLoadingConstraintForName+0x12a (0x00007F939CE1299A [libj9vm29.so+0x17599a])
j9bcv_checkClassLoadingConstraintsForSignature+0x1ba (0x00007F939CE12D6A [libj9vm29.so+0x175d6a])
javaLookupMethodImpl+0x43f (0x00007F939CD05C8F [libj9vm29.so+0x68c8f])
lookupMethod+0x7b (0x00007F939C275F0B [libjclse29.so+0x52f0b])
Java_java_lang_invoke_MethodHandleNatives_resolve+0x6a9 (0x00007F939C277209 [libjclse29.so+0x54209])
 (0x00007F931BDD8B6E [<unknown>+0x0])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2025/01/30 03:37:25 - please wait.
JVMDUMP032I JVM requested System dump using '/workspace/app/core.20250130.033725.21.0001.dmp' in response to an event
JVMPORT030W /proc/sys/kernel/core_pattern setting "|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I %h %e" specifies that the core dump is to be piped to an external program.  Attempting to rename either core or core.441.  Review the manual for the external program to find where the core dump is written and ensure the program does not truncate it.

JVMPORT049I The core file created by child process with pid = 441 was not found. Review the documentation for the /proc/sys/kernel/core_pattern program "|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I %h %e" to find where the core file is written and ensure that program does not truncate it.

JVMDUMP012E Error in System dump: /workspace/app/core.20250130.033725.21.0001.dmp
JVMDUMP032I JVM requested Java dump using '/workspace/app/javacore.20250130.033725.21.0002.txt' in response to an event
JVMDUMP010I Java dump written to /workspace/app/javacore.20250130.033725.21.0002.txt
JVMDUMP032I JVM requested Snap dump using '/workspace/app/Snap.20250130.023725.21.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /workspace/app/Snap.20250130.023725.21.0003.trc
JVMDUMP032I JVM requested JIT dump using '/workspace/app/jitdump.20250130.023725.21.0004.dmp' in response to an event
JVMDUMP051I JIT dump occurred in 'Ruby-0-Thread-37@puma threadpool 004: /opt/ibm/jruby-9.4.6.0/lib/ruby/gems/shared/gems/puma-4.3.8-java/lib/puma/thread_pool.rb:89' thread 0x0000000003D0D300
JVMDUMP053I JIT dump is recompiling java/lang/invoke/MemberName$Factory.resolve(BLjava/lang/invoke/MemberName;Ljava/lang/Class;IZ)Ljava/lang/invoke/MemberName;
JVMDUMP053I JIT dump is recompiling java/lang/invoke/MethodHandles$Lookup.resolveOrFail(BLjava/lang/Class;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;
JVMDUMP053I JIT dump is recompiling org/jruby/ir/targets/indy/CoverageSite.coverLineBootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;II)Ljava/lang/invoke/CallSite;
JVMDUMP053I JIT dump is recompiling java/lang/invoke/LambdaForm$MH/0x0000000070012940.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
JVMDUMP053I JIT dump is recompiling java/lang/invoke/BootstrapMethodInvoker.invoke(Ljava/lang/Class;Ljava/lang/invoke/MethodHandle;Ljava/lang/String;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Class;)Ljava/lang/Object;
JVMDUMP053I JIT dump is recompiling java/lang/invoke/MethodHandleNatives.linkCallSite(Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/invoke/MemberName;
JVMDUMP053I JIT dump is recompiling java/lang/invoke/MethodHandleResolver.resolveInvokeDynamic(JLjava/lang/String;Ljava/lang/String;J)Ljava/lang/Object;
JVMDUMP053I JIT dump is recompiling java/lang/invoke/LambdaForm$DMH/0x0000000099701870.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
JVMDUMP053I JIT dump is recompiling org/jruby/internal/runtime/methods/CompiledIRMethod.call(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/RubyModule;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/Block;)Lorg/jruby/runtime/builtin/IRubyObject;
JVMDUMP053I JIT dump is recompiling org/jruby/internal/runtime/methods/DynamicMethod.call(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/RubyModule;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject;
JVMDUMP053I JIT dump is recompiling org/jruby/runtime/callsite/CachingCallSite.cacheAndCall(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/RubyClass;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject;
JVMDUMP053I JIT dump is recompiling org/jruby/runtime/callsite/CachingCallSite.call(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject;
JVMDUMP053I JIT dump is recompiling org/jruby/ir/interpreter/InterpreterEngine.processCall(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/ir/instructions/Instr;Lorg/jruby/ir/Operation;Lorg/jruby/runtime/DynamicScope;Lorg/jruby/parser/StaticScope;[Ljava/lang/Object;Lorg/jruby/runtime/builtin/IRubyObject;)V
JVMDUMP053I JIT dump is recompiling org/jruby/ir/interpreter/StartupInterpreterEngine.interpret(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/Block;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/ir/interpreter/InterpreterContext;Lorg/jruby/RubyModule;Ljava/lang/String;[Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/Block;)Lorg/jruby/runtime/builtin/IRubyObject;
JVMDUMP010I JIT dump written to /workspace/app/jitdump.20250130.023725.21.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".

Diagnostic files

To be collected.

[pshipton]

Is the segmentation error still repeatable using 0.49 M2 builds?
https://github.com/ibmruntimes/semeru17-binaries/releases/tag/jdk-17.0.14%2B6_openj9-0.49.0-m2

[pshipton]

@TobiAjila @babsingh fyi

[Wojciech-H]

I will try the newer java soon. In the meantime we have downgraded to Semeru 17.0.12.1 and so far the error does not occur. Taking the frequency of occurrence of the issue with version 17.0.13 into account, it seems that the 17.0.12.1 is not affected by the issue.

[Wojciech-H]

Hi @pshipton
I've reproduced the issue with the 0.49 M2 build, as presented below. As mentioned in my previous comment, I cannot reproduce the issue with Semeru 17.0.12.1 (OpenJ9 0.46.1).

Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F9A4EB251A0 Handler2=00007F9A4EA7D7D0 InaccessibleAddress=00007F9A0A1E6074
RDI=00007F9A0A1E6074 RSI=00007F9A09E5F074 RAX=0000000000000000 RBX=00007F9A4861EFD0
RCX=00007F97C4577908 RDX=0000000000000020 R8=0000000000000001 R9=0000000000000000
R10=0000000000381500 R11=00007F9A4802AC00 R12=0000000000000000 R13=00007F9930193318
R14=00007F9A09E5EB90 R15=00007F9A4F0864A0
RIP=00007F9A4F27AAF2 GS=0000 FS=0000 RSP=00007F9A09E5EB08
EFlags=0000000000010246 CS=0033 RBP=00007F9930193318 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=00007F9A0A1E6074
xmm0=0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm1=6e616c2f6176616a (f: 1635148160.000000, d: 5.038250e+223)
xmm2=00007f97c4577908 (f: 3294066944.000000, d: 6.931238e-310)
xmm3=000000000009b000 (f: 634880.000000, d: 3.136724e-318)
xmm4=0000000002837608 (f: 42169864.000000, d: 2.083468e-316)
xmm5=0000000003efa8e0 (f: 66037984.000000, d: 3.262710e-316)
xmm6=0000000002837608 (f: 42169864.000000, d: 2.083468e-316)
xmm7=0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm8=bff5ae377dfc74f6 (f: 2113697024.000000, d: -1.355033e+00)
xmm9=4181afe5499e985e (f: 1235130496.000000, d: 3.709252e+07)
xmm10=4181afe549f8da81 (f: 1241045632.000000, d: 3.709252e+07)
xmm11=403e25a700000000 (f: 0.000000, d: 3.014708e+01)
xmm12=2020202020202020 (f: 538976256.000000, d: 6.013470e-154)
xmm13=08090a0b0c0d0e0f (f: 202182160.000000, d: 5.924543e-270)
xmm14=0200000000000000 (f: 0.000000, d: 4.778310e-299)
xmm15=0000000000000000 (f: 0.000000, d: 0.000000e+00)
Module=/lib64/libc.so.6
Module_base_address=00007F9A4F121000
Target=2_90_20250121_916 (Linux 4.18.0-348.12.2.el8_5.x86_64)
CPU=amd64 (12 logical CPUs) (0x7cd663000 RAM)
----------- Stack Backtrace -----------
__memcmp_avx2_movbe+0x12 (0x00007F9A4F27AAF2 [libc.so.6+0x159af2])
constraintHashEqualFn+0x2b (0x00007F9A4EC5F68B [libj9vm29.so+0x17a68b])
hashTableAddNodeInList+0x54 (0x00007F9A4EC54284 [libj9vm29.so+0x16f284])
registerClassLoadingConstraint+0xbe (0x00007F9A4EC5F75E [libj9vm29.so+0x17a75e])
j9bcv_checkClassLoadingConstraintForName+0x12a (0x00007F9A4EC5FA9A [libj9vm29.so+0x17aa9a])
j9bcv_checkClassLoadingConstraintsForSignature+0x1ba (0x00007F9A4EC5FE6A [libj9vm29.so+0x17ae6a])
javaLookupMethodImpl+0x42f (0x00007F9A4EB4DE0F [libj9vm29.so+0x68e0f])
lookupMethod+0x7b (0x00007F9A4D39A04B [libjclse29.so+0x5504b])
Java_java_lang_invoke_MethodHandleNatives_resolve+0x6a9 (0x00007F9A4D39B349 [libjclse29.so+0x56349])
 (0x00007F99D2310865 [<unknown>+0x0])
---------------------------------------

[pshipton]

Ok thanks. Does the exception still occur if you run with -XX:-ShareOrphans?

[Wojciech-H]

Hi @pshipton, yes - the error still occurs with the -XX:-ShareOrphans flag.

[pshipton]

@theresa-m any ideas if one of your changes might cause this regression?

https://github.com/eclipse-openj9/openj9/releases/tag/openj9-0.47.0
https://github.com/eclipse-openj9/openj9/releases/tag/openj9-0.48.0

I could try to do some intermediate builds to narrow down the list of changes.

[theresa-m]

I resolved another issue recently that was also related to one of the names passed into constraintHashEqualFn having an incorrect address. #20700

It doesn't look like this change made it into 0.49. @pshipton do we have public nightly builds that can be used to check if this change resolves the failure?

[pshipton]

@Wojciech-H pls check if the problem is resolved in the latest nightly jdk17 build.
https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK17_x86-64_linux_Nightly/933/OpenJ9-JDK17-x86-64_linux-20250207-001031.tar.gz