search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k stars 721 forks source link

crash building xmac vmState=0x000501ff #16400

Closed pshipton closed 1 year ago

pshipton commented 1 year ago

https://openj9-jenkins.osuosl.org/job/Build_JDK19_x86-64_mac_Nightly/127

https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK19_x86-64_mac_Nightly/127/Build_JDK19_x86-64_mac_Nightly-127-20221130-200617-diagnostics.tar.gz

vmState [0x501ff]: {J9VMSTATE_JIT} {inlining}

20:05:07  Type=Segmentation error vmState=0x000501ff
20:05:07  J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
20:05:07  Handler1=0000000008A37C60 Handler2=0000000008D36AB0 InaccessibleAddress=0000000000000018
20:05:07  RDI=000000000E89DF00 RSI=0000000000000000 RAX=0000000000000000 RBX=00007F88A2806BF0
20:05:07  RCX=000000000A30F838 RDX=0000000000000000 R8=00000000055FA5EB R9=FFFFFFFF00000001
20:05:07  R10=00007F88A20082B0 R11=00007F8897037C70 R12=0000000000000000 R13=000000000E89DF00
20:05:07  R14=000000000E89DF00 R15=0000000000000000
20:05:07  RIP=000000000A1BE3E5 GS=0000 FS=0000 RSP=000070000921E908
20:05:07  RFlags=0000000000010206 CS=002B RBP=000070000921E920 ERR=0000001800000004
20:05:07  TRAPNO=000000040000000E CPU=0018000000040000 FAULTVADDR=0000000000000018
20:05:07  XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM8 0f0f0f0f0f0f0f0f (f: 252645136.000000, d: 3.815737e-236)
20:05:07  XMM9 0302020102010100 (f: 33620224.000000, d: 3.524484e-294)
20:05:07  XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+00)
20:05:07  Module=/Users/jenkins/workspace/Build_JDK19_x86-64_mac_Nightly/build/macosx-x86_64-server-release/jdk/lib/default/libj9jit29.dylib
20:05:07  Module_base_address=0000000008EA4000 Symbol=instanceOfOrCheckCast
20:05:07  Symbol_address=000000000A1BE3D0
20:05:07  
20:05:07  Method_being_compiled=jdk/internal/module/ModuleInfo.doRead(Ljava/io/DataInput;)Ljdk/internal/module/ModuleInfo$Attributes;
20:05:07  Target=2_90_20221130_127 (Mac OS X 10.15.7)
20:05:07  CPU=amd64 (12 logical CPUs) (0x400000000 RAM)
20:05:07  ----------- Stack Backtrace -----------
20:05:07  instanceOfOrCheckCast+0x16 (0x000000000A1BE3E6 [libj9jit29.dylib+0x131a3e6])
20:05:07  _ZN7TR_J9VM12isInstanceOfEP19TR_OpaqueClassBlockS1_bbb+0xf9 (0x0000000008F4F4D9 [libj9jit29.dylib+0xab4d9])
20:05:07  _ZN18TR_J9SharedCacheVM12isInstanceOfEP19TR_OpaqueClassBlockS1_bbb+0x35 (0x0000000008F62205 [libj9jit29.dylib+0xbe205])
20:05:07  _ZN22TR_J9InterfaceCallSite18findCallSiteTargetEP12TR_CallStackP14TR_InlinerBase+0xf4 (0x000000000908FBB4 [libj9jit29.dylib+0x1ebbb4])
20:05:07  _ZN19TR_EstimateCodeSize12isInlineableEP12TR_CallStackP11TR_CallSite+0xa7 (0x0000000008FDB867 [libj9jit29.dylib+0x137867])
20:05:07  _ZN19InterpreterEmulator34findTargetAndUpdateInfoForCallsiteEP11TR_CallSitei+0x3e (0x000000000908CC5E [libj9jit29.dylib+0x1e8c5e])
20:05:07  _ZN19InterpreterEmulator35findAndCreateCallsitesFromBytecodesEbb+0x235 (0x000000000908AE75 [libj9jit29.dylib+0x1e6e75])
20:05:07  _ZN21TR_J9EstimateCodeSize20realEstimateCodeSizeEP13TR_CallTargetP12TR_CallStackbRN2TR6RegionE+0xb4c (0x0000000009080F8C [libj9jit29.dylib+0x1dcf8c])
20:05:07  _ZN21TR_J9EstimateCodeSize16estimateCodeSizeEP13TR_CallTargetP12TR_CallStackb+0x3f (0x00000000090803EF [libj9jit29.dylib+0x1dc3ef])
20:05:07  _ZN19TR_EstimateCodeSize17calculateCodeSizeEP13TR_CallTargetP12TR_CallStackb+0xcd (0x0000000008FDB6BD [libj9jit29.dylib+0x1376bd])
20:05:07  _ZN16TR_J9InlinerUtil29estimateAndRefineBytecodeSizeEP11TR_CallSiteP13TR_CallTargetP12TR_CallStackRi+0x9d (0x000000000907761D [libj9jit29.dylib+0x1d361d])
20:05:07  _ZN14TR_InlinerBase20applyPolicyToTargetsEP12TR_CallStackP11TR_CallSite+0x669 (0x00000000092E8F79 [libj9jit29.dylib+0x444f79])
20:05:07  _ZN14TR_InlinerBase29getSymbolAndFindInlineTargetsEP12TR_CallStackP11TR_CallSiteb+0x2de (0x00000000092DD7BE [libj9jit29.dylib+0x4397be])
20:05:07  _ZN28TR_MultipleCallTargetInliner17inlineCallTargetsEPN2TR20ResolvedMethodSymbolEP12TR_CallStackP24TR_InnerPreexistenceInfo+0x50c (0x00000000090700CC [libj9jit29.dylib+0x1cc0cc])
20:05:07  _ZN14TR_InlinerBase15performInliningEPN2TR20ResolvedMethodSymbolE+0x6f (0x00000000092DAB8F [libj9jit29.dylib+0x436b8f])
20:05:07  _ZN10TR_Inliner7performEv+0xe0 (0x000000000906E6C0 [libj9jit29.dylib+0x1ca6c0])
20:05:07  _ZN3OMR9Optimizer19performOptimizationEPK20OptimizationStrategyiii+0x1afa (0x00000000093C947A [libj9jit29.dylib+0x52547a])
20:05:07  _ZN3OMR9Optimizer8optimizeEv+0x32e (0x00000000093C764E [libj9jit29.dylib+0x52364e])
20:05:07  _ZN3OMR11Compilation7compileEv+0x5ed (0x000000000920D29D [libj9jit29.dylib+0x36929d])
20:05:07  _ZN2TR28CompilationInfoPerThreadBase7compileEP10J9VMThreadPNS_11CompilationEP17TR_ResolvedMethodR11TR_J9VMBaseP19TR_OptimizationPlanRKNS_16SegmentAllocatorE+0x7ed (0x0000000008F0A7BD [libj9jit29.dylib+0x667bd])
20:05:07  _ZN2TR28CompilationInfoPerThreadBase14wrappedCompileEP13J9PortLibraryPv+0x4bb (0x0000000008F0812B [libj9jit29.dylib+0x6412b])
20:05:07  omrsig_protect+0x392 (0x0000000008D355A2 [libj9prt29.dylib+0x215a2])
20:05:07  _ZN2TR28CompilationInfoPerThreadBase7compileEP10J9VMThreadP21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x390 (0x0000000008F032F0 [libj9jit29.dylib+0x5f2f0])
20:05:07  _ZN2TR24CompilationInfoPerThread12processEntryER21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x20a (0x0000000008F029BA [libj9jit29.dylib+0x5e9ba])
20:05:07  _ZN2TR24CompilationInfoPerThread14processEntriesEv+0x1a8 (0x0000000008F01D38 [libj9jit29.dylib+0x5dd38])
20:05:07  _ZN2TR24CompilationInfoPerThread3runEv+0xde (0x0000000008F01AFE [libj9jit29.dylib+0x5dafe])
20:05:07  _Z30protectedCompilationThreadProcP13J9PortLibraryPN2TR24CompilationInfoPerThreadE+0x90 (0x0000000008F018C0 [libj9jit29.dylib+0x5d8c0])
20:05:07  omrsig_protect+0x392 (0x0000000008D355A2 [libj9prt29.dylib+0x215a2])
20:05:07  _Z21compilationThreadProcPv+0x23c (0x0000000008EFFCAC [libj9jit29.dylib+0x5bcac])
20:05:07  thread_wrapper+0x13a (0x00000000071E26DA [libj9thr29.dylib+0xa6da])
20:05:07  _pthread_start+0x94 (0x00007FFF6F1E0109 [libsystem_pthread.dylib+0x6109])
20:05:07  ---------------------------------------
0xdaryl commented 1 year ago

@jdmpapin : please investigate this inliner crash.

jdmpapin commented 1 year ago

Can the diagnostic file collection be changed to include the JDK binaries for crashes in builds?

The diagnostics tarball does not include any of the JDK binaries, so in particular it's missing libj9jit29.dylib. The addresses printed as part of the stack trace do seem to contain code in the core, but that code doesn't correspond to the stack trace, so I'm not sure what's going on. One possibility is that even though there appears to be code there, the dylib is still required to get the correct memory contents. On Linux, this memory would simply be missing from the core. I also haven't found any way to load symbols from the dSYM without also loading the corresponding dylib.

It looks like we collect the list of files to include in the tarball with this find command:

20:06:20  + find . -name 'core.*.dmp' -o -name 'javacore.*.txt' -o -name 'Snap.*.trc' -o -name 'jitdump.*.dmp' -o -name ddr_info -o -name j9ddr.dat -o -name superset.dat -o -name '*.annt.h' -o -name '*.stub.h' -o -name '*.dSYM' -o -path '*/make-support/failure-logs/*'
20:06:20  + sed 's#^./##'
20:06:20  + tar -zcvf Build_JDK19_x86-64_mac_Nightly-127-20221130-200617-diagnostics.tar.gz -T -

I assume it leaves out the binaries because crashes usually occur in test jobs after the binaries have already been uploaded somewhere, so they're already available separately. However, when there's a crash in the build itself, as there was in this case, the binaries are not available separately (AFAICT), so they end up completely unavailable

pshipton commented 1 year ago

Makes sense. I suppose we can include ~\*.dylib \*.so \*.dll~ \*.dylib \*.soand anything else appropriate in the list of things to find. Can you open a PR?

pshipton commented 1 year ago

BTW, archive_diagnostics() is only used for building, it won't affect what happens when a test fails. Also we can leave out \*.dll since Windows would include these in the core afaik.

jdmpapin commented 1 year ago

All of the anomalies I mentioned in my previous comment went away when running LLDB on a different machine with @nbhuiyan, and there LLDB was able to load the symbols as well. We didn't manage to identify the relevant difference that allowed it to work properly there but not on the machine that I originally tried to use. At first we suspected that it was a version incompatibility, but the core was produced from a build with:

configure: Using clang C compiler version 12.0.0 [Apple clang version 12.0.0 (clang-1200.0.32.29) Target: x86_64-apple-darwin19.6.0 Thread model: posix ...]

and I was running lldb-1200.0.44.2 on Darwin 19.6.0, which seems like it should be fine.

Anyway, apparently loading symbols from dSYM does not require binaries.

A correction to my previous statement about Linux:

On Linux, this memory would simply be missing from the core.

With a bit of experimentation, I see I was mistaken. I created a small test shared library, linked a program against it, and deliberately crashed the process. Even if I delete the shared library, its code is still available from the core.

However, the binary .so does seem to be needed in order to conveniently load symbols on Linux. GDB searches for the separate debug info based on a 'debug link' filename or a build ID, which in either case is specified by the .so. LLDB doesn't know how to find the debug info file without the .so either.

That said, it does seem to be possible to load symbols from the separate debug info file alone. This is just based on my tiny experiment, so I'm not sure how reliable this method is (especially in GDB). And it's a bit of a pain, needing one command per library. In LLDB:

(lldb) add-dsym -s libfoo.so /path/to/libfoo.debuginfo

In GDB:

(gdb) add-symbol-file -o <addr> /path/to/libfoo.debuginfo

The <addr> can be found using LLDB image list. It can also be found using eu-unstrip -n --core <core> or readelf -n <core>, though the SO answer where I found these commands suggests that the latter only works if the core was generated by a new enough kernel. For some reason, GDB won't print the base address of libraries that it can't find on disk.

Given the above, I think we can leave out *.dylib, but we should include at least *.debuginfo (roughly analogous to *.dSYM), and possibly also *.so.

jdmpapin commented 1 year ago

We've crashed at this call to isInstanceOf() within TR_J9InterfaceCallSite::findCallSiteTarget() because iface is null. The value of iface comes from TR_J9InterfaceCallSite::getClassFromMethod(), which returns the result of getClassFromSignature(). The crash occurred in an AOT compilation, where getClassFromSignature() can return null. So we'll need to guard against this possibility

pshipton commented 1 year ago

Given the above, I think we can leave out .dylib, but we should include at least .debuginfo (roughly analogous to .dSYM), and possibly also .so.

It wouldn't hurt to include them all, crashes when building happen rarely. We should collect anything that may possibly be helpful. The executables could also be included so we can re-run what we build.

pshipton commented 1 year ago

Which also means including .dll and .exe for Windows.

pshipton commented 1 year ago

There is another crash which looks the same to me so I'll reopen this one.

https://openj9-jenkins.osuosl.org/job/Build_JDK11_x86-64_mac_Nightly/449

21:18:45  Unhandled exception
21:18:45  Type=Segmentation error vmState=0x000501ff
21:18:45  J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
21:18:45  Handler1=0000000004A36C00 Handler2=00000000031299F0 InaccessibleAddress=0000000000000018
21:18:45  RDI=0000000010DAD500 RSI=0000000000000000 RAX=0000000000000000 RBX=00007FED32605DE0
21:18:45  RCX=0000000006263750 RDX=0000000000000000 R8=0000000008712710 R9=FFFFFFFF00000001
21:18:45  R10=00007FED36042400 R11=00007FED2B8DEFD7 R12=0000000000000000 R13=0000000010DAD500
21:18:45  R14=0000000010DAD500 R15=0000000000000000
21:18:45  RIP=00000000061123D5 GS=0000 FS=0000 RSP=0000700003DCD878
21:18:45  RFlags=0000000000010206 CS=002B RBP=0000700003DCD890 ERR=0000001800000004
21:18:45  TRAPNO=000000040000000E CPU=0018000000040000 FAULTVADDR=0000000000000018
21:18:45  XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM8 0f0f0f0f0f0f0f0f (f: 252645136.000000, d: 3.815737e-236)
21:18:45  XMM9 0f0f0f0f0f0f0f0f (f: 252645136.000000, d: 3.815737e-236)
21:18:45  XMM10 0302020102010100 (f: 33620224.000000, d: 3.524484e-294)
21:18:45  XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+00)
21:18:45  Module=/Users/jenkins/workspace/Build_JDK11_x86-64_mac_Nightly/build/macosx-x86_64-normal-server-release/jdk/lib/default/libj9jit29.dylib
21:18:45  Module_base_address=0000000004DF8000 Symbol=instanceOfOrCheckCast
21:18:45  Symbol_address=00000000061123C0
21:18:45  
21:18:45  Method_being_compiled=sun/nio/fs/UnixChannelFactory.newFileChannel(ILsun/nio/fs/UnixPath;Ljava/lang/String;Ljava/util/Set;I)Ljava/nio/channels/FileChannel;
21:18:45  Target=2_90_20221222_449 (Mac OS X 10.15.7)
21:18:45  CPU=amd64 (12 logical CPUs) (0x400000000 RAM)
21:18:45  ----------- Stack Backtrace -----------
21:18:45  instanceOfOrCheckCast+0x16 (0x00000000061123D6 [libj9jit29.dylib+0x131a3d6])
21:18:45  _ZN7TR_J9VM12isInstanceOfEP19TR_OpaqueClassBlockS1_bbb+0xf9 (0x0000000004EA3839 [libj9jit29.dylib+0xab839])
21:18:45  _ZN18TR_J9SharedCacheVM12isInstanceOfEP19TR_OpaqueClassBlockS1_bbb+0x35 (0x0000000004EB5755 [libj9jit29.dylib+0xbd755])
21:18:45  _ZN22TR_J9InterfaceCallSite22findCallSiteTargetImplEP12TR_CallStackP14TR_InlinerBase+0x293 (0x0000000004FE2D43 [libj9jit29.dylib+0x1ead43])
21:18:45  _ZN22TR_J9InterfaceCallSite18findCallSiteTargetEP12TR_CallStackP14TR_InlinerBase+0x37 (0x0000000004FE2877 [libj9jit29.dylib+0x1ea877])
21:18:45  _ZN19TR_EstimateCodeSize12isInlineableEP12TR_CallStackP11TR_CallSite+0xa7 (0x0000000004F2E8F7 [libj9jit29.dylib+0x1368f7])
21:18:45  _ZN19InterpreterEmulator34findTargetAndUpdateInfoForCallsiteEP11TR_CallSitei+0x3e (0x0000000004FDFBFE [libj9jit29.dylib+0x1e7bfe])
21:18:45  _ZN19InterpreterEmulator35findAndCreateCallsitesFromBytecodesEbb+0x24e (0x0000000004FDDECE [libj9jit29.dylib+0x1e5ece])
21:18:45  _ZN21TR_J9EstimateCodeSize20realEstimateCodeSizeEP13TR_CallTargetP12TR_CallStackbRN2TR6RegionE+0xb4c (0x0000000004FD417C [libj9jit29.dylib+0x1dc17c])
21:18:45  _ZN21TR_J9EstimateCodeSize16estimateCodeSizeEP13TR_CallTargetP12TR_CallStackb+0x3f (0x0000000004FD35DF [libj9jit29.dylib+0x1db5df])
21:18:45  _ZN19TR_EstimateCodeSize17calculateCodeSizeEP13TR_CallTargetP12TR_CallStackb+0xcd (0x0000000004F2E74D [libj9jit29.dylib+0x13674d])
21:18:45  _ZN16TR_J9InlinerUtil29estimateAndRefineBytecodeSizeEP11TR_CallSiteP13TR_CallTargetP12TR_CallStackRi+0x9d (0x0000000004FCA80D [libj9jit29.dylib+0x1d280d])
21:18:45  _ZN14TR_InlinerBase20applyPolicyToTargetsEP12TR_CallStackP11TR_CallSite+0x669 (0x000000000523B089 [libj9jit29.dylib+0x443089])
21:18:45  _ZN14TR_InlinerBase29getSymbolAndFindInlineTargetsEP12TR_CallStackP11TR_CallSiteb+0x2de (0x000000000522F8DE [libj9jit29.dylib+0x4378de])
21:18:45  _ZN28TR_MultipleCallTargetInliner17inlineCallTargetsEPN2TR20ResolvedMethodSymbolEP12TR_CallStackP24TR_InnerPreexistenceInfo+0x50c (0x0000000004FC32BC [libj9jit29.dylib+0x1cb2bc])
21:18:45  _ZN14TR_InlinerBase15performInliningEPN2TR20ResolvedMethodSymbolE+0x6f (0x000000000522CCAF [libj9jit29.dylib+0x434caf])
21:18:45  _ZN10TR_Inliner7performEv+0xe0 (0x0000000004FC18B0 [libj9jit29.dylib+0x1c98b0])
21:18:45  _ZN3OMR9Optimizer19performOptimizationEPK20OptimizationStrategyiii+0x1afa (0x000000000531C66A [libj9jit29.dylib+0x52466a])
21:18:45  _ZN3OMR9Optimizer8optimizeEv+0x32e (0x000000000531A83E [libj9jit29.dylib+0x52283e])
21:18:45  _ZN3OMR11Compilation7compileEv+0x5ed (0x000000000515F1ED [libj9jit29.dylib+0x3671ed])
21:18:45  _ZN2TR28CompilationInfoPerThreadBase7compileEP10J9VMThreadPNS_11CompilationEP17TR_ResolvedMethodR11TR_J9VMBaseP19TR_OptimizationPlanRKNS_16SegmentAllocatorE+0x7ed (0x0000000004E5ECCD [libj9jit29.dylib+0x66ccd])
21:18:45  _ZN2TR28CompilationInfoPerThreadBase14wrappedCompileEP13J9PortLibraryPv+0x4bb (0x0000000004E5C64B [libj9jit29.dylib+0x6464b])
21:18:45  omrsig_protect+0x392 (0x00000000031284E2 [libj9prt29.dylib+0x214e2])
21:18:45  _ZN2TR28CompilationInfoPerThreadBase7compileEP10J9VMThreadP21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x390 (0x0000000004E57740 [libj9jit29.dylib+0x5f740])
21:18:45  _ZN2TR24CompilationInfoPerThread12processEntryER21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x20a (0x0000000004E56E0A [libj9jit29.dylib+0x5ee0a])
21:18:45  _ZN2TR24CompilationInfoPerThread14processEntriesEv+0x1a8 (0x0000000004E56188 [libj9jit29.dylib+0x5e188])
21:18:45  _ZN2TR24CompilationInfoPerThread3runEv+0xde (0x0000000004E55F4E [libj9jit29.dylib+0x5df4e])
21:18:45  _Z30protectedCompilationThreadProcP13J9PortLibraryPN2TR24CompilationInfoPerThreadE+0x90 (0x0000000004E55D10 [libj9jit29.dylib+0x5dd10])
21:18:45  omrsig_protect+0x392 (0x00000000031284E2 [libj9prt29.dylib+0x214e2])
21:18:45  _Z21compilationThreadProcPv+0x23c (0x0000000004E540FC [libj9jit29.dylib+0x5c0fc])
21:18:45  thread_wrapper+0x13a (0x00000000031A56DA [libj9thr29.dylib+0xa6da])
21:18:45  _pthread_start+0x94 (0x00007FFF6F1E0109 [libsystem_pthread.dylib+0x6109])
21:18:45  ---------------------------------------
jdmpapin commented 1 year ago

It seems the crash data from this more recent crash is not available. However, comparing the original backtrace:

instanceOfOrCheckCast+0x16
TR_J9VM::isInstanceOf+0xf9
TR_J9SharedCacheVM::isInstanceOf+0x35
TR_J9InterfaceCallSite::findCallSiteTarget+0xf4
...

to the new one, we can see that the crash is now occurring within findCallSiteTargetImpl():

instanceOfOrCheckCast+0x16
TR_J9VM::isInstanceOf+0xf9
TR_J9SharedCacheVM::isInstanceOf+0x35
TR_J9InterfaceCallSite::findCallSiteTargetImpl+0x293   <---- here
TR_J9InterfaceCallSite::findCallSiteTarget+0x37
...

Just by inspection I can see that findCallSiteTargetImpl() contains a separate (but nearby/related) instance of the bug that I fixed in #16429. That is, it also calls getClassFromMethod() to find the interface, and then passes the resulting interface to isInstanceOf() even though it may be null in AOT. This newer crash also occurred in an AOT compilation, which we can tell because TR_J9SharedCacheVM::isInstanceOf is on the stack.