Segfault with JITServer AOT caching, acmeair and TR_DontDisableSVMDuringStartup=1

[cjjdespres]

While testing #15949 I observed a segfault during the startup of the acmeair server:

Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F74BCF9B460 Handler2=00007F74BCDA0F90 InaccessibleAddress=0000000000000000
RDI=00000000F0B074D8 RSI=00000000FFAFB540 RAX=00000000F0B074D8 RBX=0000000000427200
RCX=0000000000000000 RDX=00000000F0AE5348 R8=00000000FFAFB540 R9=00000000F111ADD8
R10=00000000F0B07498 R11=000000000000001E R12=000000000048AD00 R13=00000000FFAFB550
R14=0000000000000004 R15=00000000FFAFB4F0
RIP=0000000000000000 GS=0000 FS=0000 RSP=00000000005953C8
EFlags=0000000000010246 CS=0033 RBP=0000000000571800 ERR=0000000000000014
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm1 00007f74b7d38120 (f: 3084091648.000000, d: 6.923800e-310)
xmm2 0000000000595609 (f: 5854729.000000, d: 2.892620e-317)
xmm3 0000000000419ae8 (f: 4299496.000000, d: 2.124233e-317)
xmm4 00000000000026e0 (f: 9952.000000, d: 4.916941e-320)
xmm5 0000000000994f80 (f: 10047360.000000, d: 4.964055e-317)
xmm6 00000000004d7c00 (f: 5078016.000000, d: 2.508873e-317)
xmm7 00000000004e50f0 (f: 5132528.000000, d: 2.535806e-317)
xmm8 0a00020000000500 (f: 1280.000000, d: 1.626768e-260)
xmm9 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm10 6d726f722839302a (f: 674836544.000000, d: 1.626926e+219)
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)
Target=2_90_20221017_000000 (Linux 5.4.0-128-generic)
CPU=amd64 (8 logical CPUs) (0x3e8850000 RAM)
----------- Stack Backtrace -----------
protectedBacktrace+0x16 (0x00007F74BCD9D4A6 [libj9prt29.so+0x254a6])
omrsig_protect+0x2b1 (0x00007F74BCDA1D91 [libj9prt29.so+0x29d91])
omrintrospect_backtrace_thread_raw+0xbf (0x00007F74BCD9D99F [libj9prt29.so+0x2599f])
omrsig_protect+0x2b1 (0x00007F74BCDA1D91 [libj9prt29.so+0x29d91])
omrintrospect_backtrace_thread+0x7e (0x00007F74BCD9D33E [libj9prt29.so+0x2533e])
generateDiagnosticFiles+0x8f (0x00007F74BCF9AF7F [libj9vm29.so+0x3cf7f])
omrsig_protect+0x2b1 (0x00007F74BCDA1D91 [libj9prt29.so+0x29d91])
vmSignalHandler+0x18f (0x00007F74BCF9B1EF [libj9vm29.so+0x3d1ef])
 (0x00007F74BD098555 [libj9vm29.so+0x13a555])

This can be reproduced somewhat reliably master (and 0.33.1) by doing the following:

1. start jitserver with AOT caching enabled
2. start an acmeair client with TR_DontDisableSVMDuringStartup=1 and have it request a particular named cache
3. wait for the client to finish starting up the web server, then stop the client
4. start an acmeair client (with or without TR_DontDisableSVMDuringStartup=1) and have it request the same named cache

Marius observed that

In one such run the stacktrace from the javacore indicates a problem during stack walking by GC:

4XENATIVESTACK               triggerDumpAgents+0x372 (0x00007F992864C342 [libj9dmp29.so+0x1f342])
4XENATIVESTACK               generateDiagnosticFiles+0x162 (0x00007F9928C959B2 [libj9vm29.so+0x3d9b2])
4XENATIVESTACK               omrsig_protect+0x2b1 (0x00007F992A2E3581 [libj9prt29.so+0x2a581])
4XENATIVESTACK               vmSignalHandler+0x17f (0x00007F9928C95B3F [libj9vm29.so+0x3db3f])
4XENATIVESTACK               mainSynchSignalHandler+0x225 (0x00007F992A2E2A75 [libj9prt29.so+0x29a75])
4XENATIVESTACK                (0x00007F9929DFA980 [libpthread.so.0+0x12980])
4XENATIVESTACK               walkStackFrames+0x49c (0x00007F9928CD688C [libj9vm29.so+0x7e88c])
4XENATIVESTACK               _ZN28GC_VMThreadStackSlotIterator9scanSlotsEP10J9VMThreadS1_PvPFvP8J9JavaVMPP8J9ObjectS2_P16J9StackWalkStatePKvEbb+0x76 (0x00007F9922CA9556 [libj9gc29.so+0x42556])
4XENATIVESTACK               _ZN14MM_RootScanner13scanOneThreadEP18MM_EnvironmentBaseP10J9VMThreadPv+0x101 (0x00007F9922CA0C51 [libj9gc29.so+0x39c51])
4XENATIVESTACK               _ZN14MM_RootScanner11scanThreadsEP18MM_EnvironmentBase+0xbf (0x00007F9922CA018F [libj9gc29.so+0x3918f])
4XENATIVESTACK               _ZN14MM_RootScanner9scanRootsEP18MM_EnvironmentBase+0x43 (0x00007F9922CA2C93 [libj9gc29.so+0x3bc93])

Attn @mpirvu @AlexeyKhrabrov. I think this is the extent of the conversation we had in that PR regarding this bug.

[cjjdespres]

By excluding org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources* from JIT compilation the error no longer occurs.

[mpirvu]

Is it possible to limit this to just one method?
Then, the next step is to simplify the compilation as much as possible by reducing opt level, disabling inlining etc.
Then, we need to generate compilation logs and compare with the logs from a successful run.

[cjjdespres]

I will investigate that.

[cjjdespres]

I can get a segfault somewhat reliably with a three-line limit file:

+ (cold) org/eclipse/osgi/internal/loader/classpath/ClasspathEntry.findResource(Ljava/lang/String;Lorg/eclipse/osgi/container/Module;I)Ljava/net/URL; @ 00007F0536F85528-00007F0536F859B1 OrdinaryMethod - Q_SZ=9 Q_SZI=9 QW=114 j9m=00000000004E6630 bcsz=65 remote compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=43%
+ (AOT warm) org/eclipse/osgi/internal/framework/ContextFinder.checkClassLoader(Ljava/lang/ClassLoader;)Z @ 00007F0536F85A00-00007F0536F85F9D OrdinaryMethod - Q_SZ=8 Q_SZI=8 QW=102 j9m=00000000003D8BE0 bcsz=40 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=43%
+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;[ILjava/util/List;)V @ 00007F0536F85FE8-00007F0536F865CA OrdinaryMethod - Q_SZ=3 Q_SZI=3 QW=32 j9m=00000000004E5110 bcsz=72 remote compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=43%

Note that with this file the segfault will occur during the first connection (not the subsequent connection as reported in the first comment). It does still seem to require full AOT caching enabled at both client and server. It doesn't appear to occur with a smaller file.

Sometimes there is only a single segfault as I reported in the first comment above, but often there is a double segfault, the second one looking like:

Type=Segmentation error vmState=0x0002000f
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000080
Handler1=00007FA25F3F04B0 Handler2=00007FA25F1F63E0 InaccessibleAddress=0000000000000000
RDI=00007FA1FC007650 RSI=00007FA25C299D78 RAX=FFFFFFFFFFFFFFFC RBX=FFFFFFFFFFFFFFFD
RCX=20007FA1FC00764C RDX=07FFFFFFFFFFFFFF R8=00000000000000B6 R9=00007FA21C59C604
R10=00007FA25C299D60 R11=0000000000000000 R12=00007FA25C299D48 R13=0000000000000001
R14=00007FA25C299D50 R15=0000000000000000
RIP=00007FA25F5084D5 GS=0000 FS=0000 RSP=00007FA25C299CC0
EFlags=0000000000010A07 CS=0033 RBP=00007FA21C59C60C ERR=0000000000000000
TRAPNO=000000000000000D OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm1 5f60854000000000 (f: 0.000000, d: 2.703904e+151)
xmm2 00000000b7654321 (f: 3076866816.000000, d: 1.520174e-314)
xmm3 00000000000000c1 (f: 193.000000, d: 9.535467e-322)
xmm4 00007fa25e008199 (f: 1577091456.000000, d: 6.933487e-310)
xmm5 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm6 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm7 00007fa25e008199 (f: 1577091456.000000, d: 6.933487e-310)
xmm8 007200650073002e (f: 7536686.000000, d: 1.602190e-306)
xmm9 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm10 0710260119001413 (f: 419435552.000000, d: 1.166044e-274)
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=/opt/ol/wlp/usr/servers/defaultServer/jdk/lib/default/libj9vm29.so
Module_base_address=00007FA25F3B3000
Target=2_90_20221114_000000 (Linux 5.4.0-132-generic)
CPU=amd64 (8 logical CPUs) (0x3e884e000 RAM)
----------- Stack Backtrace -----------
j9stackmap_StackBitsForPC+0x8d5 (0x00007FA25F5084D5 [libj9vm29.so+0x1554d5])
walkBytecodeFrameSlots+0x2d5 (0x00007FA25F432B95 [libj9vm29.so+0x7fb95])
walkStackFrames+0xa81 (0x00007FA25F433911 [libj9vm29.so+0x80911])
_ZN28GC_VMThreadStackSlotIterator9scanSlotsEP10J9VMThreadS1_PvPFvP8J9JavaVMPP8J9ObjectS2_P16J9StackWalkStatePKvEbb+0x40 (0x00007FA25DE18FC0 [libj9gc29.so+0x44fc0])
_ZN14MM_RootScanner13scanOneThreadEP18MM_EnvironmentBaseP10J9VMThreadPv+0x105 (0x00007FA25DE0FFC5 [libj9gc29.so+0x3bfc5])
_ZN14MM_RootScanner11scanThreadsEP18MM_EnvironmentBase+0xbf (0x00007FA25DE0EEEF [libj9gc29.so+0x3aeef])
_ZN14MM_RootScanner9scanRootsEP18MM_EnvironmentBase+0x4b (0x00007FA25DE11D4B [libj9gc29.so+0x3dd4b])
_ZN12MM_Scavenger24workThreadGarbageCollectEP22MM_EnvironmentStandard+0x36b (0x00007FA25DF5309B [libj9gc29.so+0x17f09b])
_ZN21MM_ParallelDispatcher16workerEntryPointEP18MM_EnvironmentBase+0x228 (0x00007FA25DEFF498 [libj9gc29.so+0x12b498])
_Z23dispatcher_thread_proc2P14OMRPortLibraryPv+0x111 (0x00007FA25DEFEC71 [libj9gc29.so+0x12ac71])
omrsig_protect+0x2b1 (0x00007FA25F1F71E1 [libj9prt29.so+0x2a1e1])
dispatcher_thread_proc+0x43 (0x00007FA25DEFE6B3 [libj9gc29.so+0x12a6b3])
thread_wrapper+0x187 (0x00007FA25F39DAF7 [libj9thr29.so+0xbaf7])
start_thread+0xd9 (0x00007FA25F6AC609 [libpthread.so.0+0x8609])
clone+0x43 (0x00007FA25F808133 [libc.so.6+0x11f133])

which matches the stack trace you posted.

[mpirvu]

There are 2 AOT compilations and a non AOT one. If this is an AOT caching problem I expect the issue to be with one of the AOT methods.
I suggest to compile only of them with AOT (you may need to hack the code).
Also useful would be to compile only one remote.

[cjjdespres]

Looking at the vlog of another run with a crash, I can see that findResource and checkClassLoader were both (cold), and findLocalResources was (AOT warm), so it's probably findLocalResources.

[cjjdespres]

Using my work toward #15399 (that I haven't submitted as a PR yet) I was able to exclude findLocalResources from JITServer AOT cache loading and eliminate the segfault. Excluding checkClassLoader does not eliminate the segfault.

[mpirvu]

I managed to reproduce a crash with the following limit directive:
limit={org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResource*}

The compilations performed are:

+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;)Ljava/util/Enumeration; @ 00007FA497471060-00007FA497471CA8 OrdinaryMethod - Q_SZ=10 Q_SZI=10 QW=108 j9m=00000000004F35D0 bcsz=196 remote deserialized compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=50%
+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;[ILjava/util/List;)V @ 00007FA497371068-00007FA497371B5A OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=18 j9m=00000000004F35F0 bcsz=72 remote deserialized compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=50%
! (AOT load) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;)Ljava/util/Enumeration; Q_SZ=1 Q_SZI=1 QW=2 j9m=00000000004F35D0 time=271us compilationRelocationFailure (trampolineRelocationFailure) memLimit=262144 KB compThreadID=1
+ (cold) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;)Ljava/util/Enumeration; @ 00007FA0D0FE8D00-00007FA0D0FE99A2 OrdinaryMethod - Q_SZ=12 Q_SZI=12 QW=80 j9m=00000000004F35D0 bcsz=196 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=50%
! (AOT load) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;[ILjava/util/List;)V Q_SZ=12 Q_SZI=12 QW=85 j9m=00000000004F35F0 time=536us compilationRelocationFailure (trampolineRelocationFailure) memLimit=262144 KB compThreadID=1
+ (cold) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;[ILjava/util/List;)V @ 00007FA0D0FEA548-00007FA0D0FEA7DA OrdinaryMethod - Q_SZ=12 Q_SZI=12 QW=85 j9m=00000000004F35F0 bcsz=72 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=50%
+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResource(Ljava/lang/String;)Ljava/net/URL; @ 00007FA497471060-00007FA497471A97 OrdinaryMethod - Q_SZ=5 Q_SZI=5 QW=12 j9m=00000000004F3570 bcsz=180 remote deserialized compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=68%
+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResourceImpl(Ljava/lang/String;I)Ljava/net/URL; @ 00007FA497471068-00007FA49747188C OrdinaryMethod - Q_SZ=4 Q_SZI=4 QW=10 j9m=00000000004F3590 bcsz=174 remote deserialized compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=68%
+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResourceImpl(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;I[I)Ljava/net/URL; @ 00007FA497471068-00007FA497471A93 OrdinaryMethod - Q_SZ=3 Q_SZI=3 QW=8 j9m=00000000004F35B0 bcsz=81 remote deserialized compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=68%
! (AOT load) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResource(Ljava/lang/String;)Ljava/net/URL; Q_SZ=2 Q_SZI=2 QW=3 j9m=00000000004F3570 time=313us compilationRelocationFailure (trampolineRelocationFailure) memLimit=262144 KB compThreadID=1
+ (cold) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResource(Ljava/lang/String;)Ljava/net/URL; @ 00007FA0D0FEB2A0-00007FA0D0FEC102 OrdinaryMethod - Q_SZ=2 Q_SZI=2 QW=3 j9m=00000000004F3570 bcsz=180 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=42%
+ (AOT load) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResourceImpl(Ljava/lang/String;I)Ljava/net/URL; @ 00007FA0D0FEC168-00007FA0D0FEC98C Q_SZ=1 Q_SZI=1 QW=2 j9m=00000000004F3590 bcsz=174 compThreadID=1
+ (AOT load) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResourceImpl(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;I[I)Ljava/net/URL; @ 00007FA0D0FEC9E8-00007FA0D0FED413 Q_SZ=0 Q_SZI=0 QW=1 j9m=00000000004F35B0 bcsz=81 compThreadID=1

I believe that only ClasspathManager.findLocalResourceImpl routines are problematic, because for all the others the AOT load fail and we end-up doing a cold non-AOT compilation.
If I try to limit further, then the AOT loads for ClasspathManager.findLocalResourceImpl fail and the crash disappears.

[mpirvu]

It we can eliminate that trampolineRelocationFailure we may be able to limit the compilations further.

[mpirvu]

I have added -Xjit:enableJITServerHeuristics so that cheap compilations are performed locally. With this, the only remote compilations that get used (after an AOT load) are the two ClasspathManager.findLocalResourceImpl

[mpirvu]

I just had a crash where the only successful AOT load was:
+ (AOT load) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResourceImpl(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;I[I)Ljava/net/URL; @ 00007F2C123D2E88-00007F2C123D38B3 Q_SZ=0 Q_SZI=0 QW=1 j9m=000000000050DFB0 bcsz=81 compThreadID=1
I am guessing that the problem must lie in this method.

[mpirvu]

I was trying to understand why we have those AOT load failures due to trampoline relocation and it turns out that messages are wrong. We actually have thunk relocation failures.

[cjjdespres]

An update to this issue:

I can reproduce this fairly consistently using the openj9 commit immediately before #16625 was merged using only -XX:+UseJITServer -Xaot:forceAOT (so no JITServer AOT caching at all) and the following limit file:

+ (AOT warm) org/apache/felix/scr/impl/BundleComponentActivator.findDescriptors(Lorg/osgi/framework/Bundle;Ljava/lang/String;)[Ljava/net/URL; @ 00007F590B527060-00007F590B52919A OrdinaryMethod - Q_SZ=10 Q_SZI=10 QW=112 j9m=0000000000602030 bcsz=149 remote compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=63%
+ (cold) org/eclipse/osgi/internal/loader/classpath/ClasspathEntry.findResource(Ljava/lang/String;Lorg/eclipse/osgi/container/Module;I)Ljava/net/URL; @ 00007F590B529888-00007F590B529D11 OrdinaryMethod - Q_SZ=14 Q_SZI=14 QW=166 j9m=00000000004E6630 bcsz=65 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=63%
+ (AOT warm) java/util/stream/Sink.begin(J)V @ 00007F590B529D60-00007F590B529D8F OrdinaryMethod - Q_SZ=19 Q_SZI=19 QW=202 j9m=000000000027D298 bcsz=1 remote compThreadID=2 CpuLoad=0%(0%avg) JvmCpu=63%
+ (AOT warm) java/lang/ModuleLayer.getServicesCatalog()Ljdk/internal/module/ServicesCatalog; @ 00007F590B529DE0-00007F590B52AABA OrdinaryMethod - Q_SZ=18 Q_SZI=18 QW=200 j9m=000000000013A400 bcsz=91 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=63%
+ (cold) org/eclipse/osgi/internal/framework/ContextFinder.checkClassLoader(Ljava/lang/ClassLoader;)Z @ 00007F590B52B160-00007F590B52B2E8 OrdinaryMethod - Q_SZ=24 Q_SZI=24 QW=230 j9m=00000000003D8BE0 bcsz=40 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=63%
+ (AOT warm) org/eclipse/osgi/internal/framework/ContextFinder.basicFindClassLoaders()Ljava/util/List; @ 00007F590B52B340-00007F590B52BDFA OrdinaryMethod - Q_SZ=22 Q_SZI=22 QW=206 j9m=00000000003D8BC0 bcsz=112 remote compThreadID=2 CpuLoad=0%(0%avg) JvmCpu=63%
+ (cold) java/util/ServiceLoader$LazyClassPathLookupIterator.nextProviderClass()Ljava/lang/Class; @ 00007F590B52DFC0-00007F590B52EAA0 OrdinaryMethod - Q_SZ=31 Q_SZI=31 QW=248 j9m=0000000000188B50 bcsz=248 remote compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=63%
+ (AOT warm) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;[Lorg/eclipse/osgi/internal/loader/classpath/ClasspathEntry;Lorg/eclipse/osgi/container/Module;[ILjava/util/List;)V @ 00007F590B52EAE8-00007F590B52F0CA OrdinaryMethod - Q_SZ=31 Q_SZI=31 QW=248 j9m=00000000004E5110 bcsz=72 remote compThreadID=2 CpuLoad=0%(0%avg) JvmCpu=63%
+ (cold) org/eclipse/osgi/internal/loader/classpath/ClasspathManager.findLocalResources(Ljava/lang/String;)Ljava/util/Enumeration; @ 00007F590B52F120-00007F590B52FA99 OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=24 j9m=00000000004E50F0 bcsz=196 remote compThreadID=1 CpuLoad=0%(0%avg) JvmCpu=63%
+ (cold) org/eclipse/osgi/internal/framework/ContextFinder.getResources(Ljava/lang/String;)Ljava/util/Enumeration; @ 00007F590B531800-00007F590B532076 OrdinaryMethod - Q_SZ=13 Q_SZI=13 QW=100 j9m=00000000003D8CC0 bcsz=100 remote compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=63%
+ (AOT warm) java/util/TreeSet.contains(Ljava/lang/Object;)Z @ 00007F590B5320C0-00007F590B532222 OrdinaryMethod - Q_SZ=5 Q_SZI=5 QW=36 j9m=0000000000541FA8 bcsz=11 remote compThreadID=0 CpuLoad=0%(0%avg) JvmCpu=57%

I cannot reproduce this segfault after incorporating the changes from #16625.

[mpirvu]

I cannot reproduce this segfault after incorporating the changes from #16625.
Closing the issue based on the comment above.