Openj9: Dacapo sub-benchmark "eclipse" crashes when run with large load
Java -version output
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-201910110340-b08)
Eclipse OpenJ9 VM (build master-fe39103a7, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20191011_432 (JIT enabled, AOT enabled)
OpenJ9 - fe39103a7
OMR - bc5ceea7
JCL - 660f897065 based on jdk8u232-b08)
Summary of problem
The benchmark runs fine with default and small size workloads. Only with "large" size, this issue is observed.
HotSpot build works fine even with large size.
Command used to run the benchmark:
java -jar ../dacapo/dacapo-9.12-MR1-bach.jar -s large eclipse
Platform: Linux X64
Below is the error I get:
Unzip workspace
===== DaCapo 9.12-MR1 eclipse starting =====
Initialize workspace ..............................................................
Index workspace #0: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x791045) [0x7fe721417045]
#1: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x79be80) [0x7fe721421e80]
#2: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x1287be) [0x7fe720dae7be]
#3: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9prt29.so(+0x200aa) [0x7fe722af50aa]
#4: /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390) [0x7fe724e86390]
#5: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x713ed4) [0x7fe721399ed4]
#6: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x71404d) [0x7fe72139a04d]
#7: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x71480b) [0x7fe72139a80b]
#8: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x60f3c9) [0x7fe7212953c9]
#9: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x60ed69) [0x7fe721294d69]
#10: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x6101db) [0x7fe7212961db]
#11: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x400fd1) [0x7fe721086fd1]
#12: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x136ce8) [0x7fe720dbcce8]
#13: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x137b22) [0x7fe720dbdb22]
#14: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9prt29.so(+0x20be3) [0x7fe722af5be3]
#15: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x139589) [0x7fe720dbf589]
#16: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x139ab2) [0x7fe720dbfab2]
#17: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x135b2b) [0x7fe720dbbb2b]
#18: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x135e4a) [0x7fe720dbbe4a]
#19: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x135f0a) [0x7fe720dbbf0a]
#20: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9prt29.so(+0x20be3) [0x7fe722af5be3]
#21: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so(+0x136364) [0x7fe720dbc364]
#22: /java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9thr29.so(+0xe156) [0x7fe722f64156]
#23: /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fe724e7c6ba]
#24: function clone+0x6d [0x7fe72479641d]
Unhandled exception
Type=Floating point error vmState=0x000536ff
J9Generic_Signal_Number=00000888 Signal_Number=00000008 Error_Value=00000000 Signal_Code=00000001
Handler1=00007FE723210830 Handler2=00007FE722AF4E80
RDI=00007FE6480142D0 RSI=0000000000000000 RAX=0000000000002710 RBX=00007FE64809F870
RCX=0000000000002710 RDX=0000000000000000 R8=00000000000002A3 R9=0000000000000000
R10=0000000000000010 R11=00007FE724825150 R12=00007FE67FC45C20 R13=00007FE67FDE0000
R14=000000000000029B R15=000000000000029A
RIP=00007FE721399ED4 GS=0000 FS=0000 RSP=00007FE709C91150
EFlags=0000000000010246 CS=0033 RBP=00007FE709C91370 ERR=0000000000000000
TRAPNO=0000000000000000 OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm1 00007fe648031450 (f: 1208161408.000000, d: 6.947898e-310)
xmm2 00007fe6480313f0 (f: 1208161280.000000, d: 6.947898e-310)
xmm3 00007fe648031390 (f: 1208161152.000000, d: 6.947898e-310)
xmm4 00007fe648031330 (f: 1208161024.000000, d: 6.947898e-310)
xmm5 00007fe6480311b0 (f: 1208160640.000000, d: 6.947898e-310)
xmm6 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm7 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm8 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm9 000d021e09180205 (f: 152568320.000000, d: 1.809023e-308)
xmm10 05000f09430b1e03 (f: 1124802048.000000, d: 1.349912e-284)
xmm11 0000000049d70a38 (f: 1238829568.000000, d: 6.120632e-315)
xmm12 000000004689a022 (f: 1183424512.000000, d: 5.846894e-315)
xmm13 0000000047ac082f (f: 1202456576.000000, d: 5.940925e-315)
xmm14 0000000048650dc0 (f: 1214582272.000000, d: 6.000833e-315)
xmm15 0000000046b73e38 (f: 1186414080.000000, d: 5.861665e-315)
Module=/java/O8_j9_lnx64-20191011/jre/lib/amd64/compressedrefs/libj9jit29.so
Module_base_address=00007FE720C86000
Method_being_compiled=org/eclipse/jdt/internal/compiler/parser/Parser.consumeRule(I)V
Target=2_90_20191011_432 (Linux 4.4.0-164-generic)
CPU=amd64 (16 logical CPUs) (0xbc9342000 RAM)
----------- Stack Backtrace -----------
(0x00007FE721399ED4 [libj9jit29.so+0x713ed4])
(0x00007FE72139A04D [libj9jit29.so+0x71404d])
(0x00007FE72139A80B [libj9jit29.so+0x71480b])
(0x00007FE7212953C9 [libj9jit29.so+0x60f3c9])
(0x00007FE721294D69 [libj9jit29.so+0x60ed69])
(0x00007FE7212961DB [libj9jit29.so+0x6101db])
(0x00007FE721086FD1 [libj9jit29.so+0x400fd1])
(0x00007FE720DBCCE8 [libj9jit29.so+0x136ce8])
(0x00007FE720DBDB22 [libj9jit29.so+0x137b22])
(0x00007FE722AF5BE3 [libj9prt29.so+0x20be3])
(0x00007FE720DBF589 [libj9jit29.so+0x139589])
(0x00007FE720DBFAB2 [libj9jit29.so+0x139ab2])
(0x00007FE720DBBB2B [libj9jit29.so+0x135b2b])
(0x00007FE720DBBE4A [libj9jit29.so+0x135e4a])
(0x00007FE720DBBF0A [libj9jit29.so+0x135f0a])
(0x00007FE722AF5BE3 [libj9prt29.so+0x20be3])
(0x00007FE720DBC364 [libj9jit29.so+0x136364])
(0x00007FE722F64156 [libj9thr29.so+0xe156])
(0x00007FE724E7C6BA [libpthread.so.0+0x76ba])
clone+0x6d (0x00007FE72479641D [libc.so.6+0x10741d])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2019/10/14 20:19:52 - please wait.
JVMDUMP032I JVM requested System dump using '/java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/core.20191014.201952.3847.0001.dmp' in response to an event
JVMPORT030W /proc/sys/kernel/core_pattern setting "|/usr/share/apport/apport %p %s %c %d %P" specifies that the core dump is to be piped to an external program. Attempting to rename either core or core.3945.
JVMDUMP010I System dump written to /java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/core.20191014.201952.3847.0001.dmp
JVMDUMP032I JVM requested Java dump using '/java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/javacore.20191014.201952.3847.0002.txt' in response to an event
JVMDUMP010I Java dump written to /java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/javacore.20191014.201952.3847.0002.txt
JVMDUMP032I JVM requested Snap dump using '/java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/Snap.20191014.201952.3847.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/Snap.20191014.201952.3847.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/jitdump.20191014.201952.3847.0004.dmp'
...............................................................
#JITDUMP: vmThread=0000000000F49B00 Recursive crash occurred. Aborting JIT dump.JVMDUMP010I JIT dump written to /java/rt-cloud/rt-cloud-benchmarks-master/dacapo/scripts/jitdump.20191014.201952.3847.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
kusumachalasani
All 16 comments
@mpirvu @vijaysun-omr FYI
kusumachalasani
on 14 Oct 2019
@andrewcraik
java -Xjit:vmState=0x000536ff -version
vmState [0x536ff]: {J9VMSTATE_JIT_CODEGEN} {switchAnalyzer}
I don't know if that's correct though.
mpirvu
on 14 Oct 2019
Flagging as high priority as it's a crash
DanHeidinga
on 14 Oct 2019
So there is a large table lookup at the top of the jitdump in the javacores that were attached. The recompile did not generate any useful info in that dump. The table look up has about 600 entries and multiple entries that all go to the same place - block_422 which is a return. I did manage to get a crash running on my local machine running that benchmark as specified so I'm just trying to get some details about where the crash is happening to see what the problem is.
andrewcraik
on 15 Oct 2019
So the crash looks to be at https://github.com/eclipse/omr/blob/42aab208572031037e55f0c915a36e6b40def177/compiler/optimizer/SwitchAnalyzer.cpp#L1347 due to a divide by zero. The divide by zero apparently indicates an unreachable successor according to the assert in the code specified. Continuing investigation to see what has happened to cause an unreachable successor and how it happened...
andrewcraik
on 15 Oct 2019
Ok so here's the problem - in the crash block_422 is a successor of multiple table cases (256 to be exact) - so many that the int8_t counter for the number of successors going to the block overflows... This results in a division by zero if the overflow results in a zero (note signed overflow behaviour is undefined by the spec but an overflow to zero is one possible outcome). The case is rare because if the number overflows to some non-zero value the division will work - it just won't make much sense...
This code has been unmodified for a long time - for some reason we have just started hitting the corner case of 0. Increasing the size of the counter to int32_t will ensure we don't overflow.
Pull request against OMR https://github.com/eclipse/omr/pull/4450.
andrewcraik
on 15 Oct 2019
OMR change has been merged. I believe this is now fixed so marking closed. Please reopen if this is still a problem with the change added to the VM.
andrewcraik
on 5 Nov 2019
I am seeing an intermittent crash when running dacapo-eclipse on aarch64
Link to Deep history
[2021-01-06T17:39:24.624Z] Index workspace ....................#0: /home/jenkins/workspace/Test_openjdk8_j9_sanity.perf_aarch64_linux/openjdkbinary/j2sdk-image/jre/lib/aarch64/compressedrefs/libj9jit29.so(+0x6e0594) [0xffffa640d594]
[2021-01-06T17:39:24.625Z] #1: /home/jenkins/workspace/Test_openjdk8_j9_sanity.perf_aarch64_linux/openjdkbinary/j2sdk-image/jre/lib/aarch64/compressedrefs/libj9jit29.so(+0x6eb710) [0xffffa6418710]
[2021-01-06T17:39:24.625Z] #2: /home/jenkins/workspace/Test_openjdk8_j9_sanity.perf_aarch64_linux/openjdkbinary/j2sdk-image/jre/lib/aarch64/compressedrefs/libj9jit29.so(+0x110244) [0xffffa5e3d244]
[2021-01-06T17:39:24.625Z] #3: /home/jenkins/workspace/Test_openjdk8_j9_sanity.perf_aarch64_linux/openjdkbinary/j2sdk-image/jre/lib/aarch64/compressedrefs/libj9prt29.so(+0x24368) [0xffffa694b368]
[2021-01-06T17:39:24.625Z] Unhandled exception
[2021-01-06T17:39:24.625Z] Type=Segmentation error vmState=0x000516ff
[2021-01-06T17:39:24.625Z] J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
[2021-01-06T17:39:24.625Z] Handler1=0000FFFFA6A7B9EC Handler2=0000FFFFA694B1F0 InaccessibleAddress=0000FFFF00000013
[2021-01-06T17:39:24.625Z] R0=0000000000000010 R1=0000000000000006 R2=0000000000000003 R3=0000FFFF00000003
[2021-01-06T17:39:24.625Z] R4=0000FFFF3284A2C0 R5=0000000000000005 R6=0000000000000005 R7=0000000000000005
[2021-01-06T17:39:24.625Z] R8=0000000000000000 R9=0000000000000000 R10=0000000000000000 R11=0000000000000000
[2021-01-06T17:39:24.625Z] R12=0000000000000003 R13=0000000000000000 R14=0000000000000000 R15=0000FFFFA66D7880
[2021-01-06T17:39:24.625Z] R16=0000FFFFA66AD138 R17=0000FFFFA7538800 R18=0000000000000000 R19=0000FFFF325B1420
[2021-01-06T17:39:24.625Z] R20=0000FFFF3284A2A0 R21=0000FFFF32494E90 R22=0000000000000038 R23=0000FFFF32916B40
[2021-01-06T17:39:24.625Z] R24=0000FFFF32848D30 R25=00000000000001C0 R26=0000000000000018 R27=0000FFFF329018B0
[2021-01-06T17:39:24.625Z] R28=0000000000000001 R29=0000FFFF89DE0F60 R30=0000FFFFA6335BD4 R31=0000FFFF89DD8DD0
[2021-01-06T17:39:24.625Z] PC=0000FFFFA6335EEC SP=0000FFFF89DD8DD0 PSTATE=0000000080000000
[2021-01-06T17:39:24.625Z] V0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V1 a6bc49f000000000 (f: 0.000000, d: -4.279338e-122)
[2021-01-06T17:39:24.625Z] V2 0000ffffa6bc49f0 (f: 2797357568.000000, d: 1.390664e-309)
[2021-01-06T17:39:24.625Z] V3 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V4 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V5 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V6 3333333333333333 (f: 858993472.000000, d: 4.667261e-62)
[2021-01-06T17:39:24.625Z] V7 0000000000000007 (f: 7.000000, d: 3.458460e-323)
[2021-01-06T17:39:24.625Z] V8 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V9 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V10 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V11 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V12 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V13 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V14 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V15 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V16 ffffffffffffffff (f: 4294967296.000000, d: -nan)
[2021-01-06T17:39:24.625Z] V17 0f0f0f0f0f0f0f0f (f: 252645136.000000, d: 3.815737e-236)
[2021-01-06T17:39:24.625Z] V18 5555555555555555 (f: 1431655808.000000, d: 1.194531e+103)
[2021-01-06T17:39:24.625Z] V19 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V20 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V21 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V22 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V23 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V24 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V25 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V26 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V27 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V28 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V29 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V30 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] V31 0000000000000000 (f: 0.000000, d: 0.000000e+00)
[2021-01-06T17:39:24.625Z] Module=/home/jenkins/workspace/Test_openjdk8_j9_sanity.perf_aarch64_linux/openjdkbinary/j2sdk-image/jre/lib/aarch64/compressedrefs/libj9jit29.so
[2021-01-06T17:39:24.625Z] Module_base_address=0000FFFFA5D2D000
[2021-01-06T17:39:24.625Z]
[2021-01-06T17:39:24.625Z] Method_being_compiled=org/eclipse/jdt/internal/compiler/util/HashtableOfObject.rehash()V
[2021-01-06T17:39:24.625Z] Target=2_90_20210106_186 (Linux 4.15.0-34-generic)
[2021-01-06T17:39:24.625Z] CPU=aarch64 (64 logical CPUs) (0x1f699a1000 RAM)
[2021-01-06T17:39:24.625Z] ----------- Stack Backtrace -----------
[2021-01-06T17:39:24.625Z] (0x0000FFFFA696CA48 [libj9prt29.so+0x45a48])
smlambert
on 8 Jan 2021
@0xdaryl @knn-k fyi. Unless there is a quick fix, better to create a new issue rather than re-opening this old resolved issue.
pshipton
on 8 Jan 2021
https://trss.adoptopenjdk.net/output/test?id=5ff616932bad78506601ca3a
How can I know which aarch64 build was used in the run?
[2021-01-06T17:39:24.625Z] Handler1=0000FFFFA6A7B9EC Handler2=0000FFFFA694B1F0 InaccessibleAddress=0000FFFF00000013
[2021-01-06T17:39:24.625Z] R0=0000000000000010 R1=0000000000000006 R2=0000000000000003 R3=0000FFFF00000003
It looks like it failed by accessing the address R3 + 0x10.
knn-k
on 12 Jan 2021
It is not the JDK 8 0.24m2 build.
There is no instruction accessing x3+0x10 around offset 0x608eec of libj9jit29.so of that build.
0000000000608eb8 <_ZN20TR_PrefetchInsertion15createDeltaNodeEPN2TR4NodeES2_i>:
608eb8: a9bc53f3 stp x19, x20, [sp, #-64]!
608ebc: eb02003f cmp x1, x2
608ec0: f9000bf5 str x21, [sp, #16]
608ec4: aa0203f5 mov x21, x2
608ec8: f90013f7 str x23, [sp, #32]
608ecc: 2a0303f7 mov w23, w3
608ed0: f9001bfe str x30, [sp, #48]
608ed4: 540005e0 b.eq 608f90 <_ZN20TR_PrefetchInsertion15createDeltaNodeEPN2TR4NodeES2_i+0xd8> // b.none
608ed8: f9000ff6 str x22, [sp, #24]
608edc: aa0103f3 mov x19, x1
608ee0: aa0103f6 mov x22, x1
608ee4: 79400834 ldrh w20, [x1, #4]
608ee8: 34000474 cbz w20, 608f74 <_ZN20TR_PrefetchInsertion15createDeltaNodeEPN2TR4NodeES2_i+0xbc>
608eec: f90017f8 str x24, [sp, #40]
608ef0: aa0003f8 mov x24, x0
608ef4: f0001ba0 adrp x0, 97f000 <_GLOBAL_OFFSET_TABLE_+0x3048>
608ef8: b9400036 ldr w22, [x1]
608efc: f9468800 ldr x0, [x0, #3344]
How can I know which aarch64 build was used in the run?
From the link you shared, the pipeline "tree" is at the top of the page:
which can be clicked on to see details, or get to the Jenkins job directly where we print out the java -version output:
12:34:58 =JAVA VERSION OUTPUT BEGIN=
12:34:58 openjdk version "1.8.0_282-internal"
12:34:58 OpenJDK Runtime Environment (build 1.8.0_282-internal-202101061710-b07)
12:34:58 Eclipse OpenJ9 VM (build master-aa9ca0070, JRE 1.8.0 Linux aarch64-64-Bit Compressed References 20210106_186 (JIT enabled, AOT enabled)
12:34:58 OpenJ9 - aa9ca0070
12:34:58 OMR - 13926a736
12:34:58 JCL - 722ab284 based on jdk8u282-b07)
12:34:58 =JAVA VERSION OUTPUT END=
@smlambert Thank you.
The binary with https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-aarch64-openj9/186/ seems to be no longer available.
The available binary from build 189 does not match the register dump above, unfortunately.
608ed0: b9401420 ldr w0, [x1, #20]
608ed4: 294290e3 ldp w3, w4, [x7, #20]
608ed8: 6b00009f cmp w4, w0
608edc: 7a43a041 ccmp w2, w3, #0x1, ge // ge = tcont
608ee0: 54002a8a b.ge 609430 <_ZN23TR_ExceptionCheckMotion7performEv+0x990> // b.tcont
608ee4: 6b00005f cmp w2, w0
608ee8: 5400012b b.lt 608f0c <_ZN23TR_ExceptionCheckMotion7performEv+0x46c> // b.tstop
608eec: 937d7c02 sbfiz x2, x0, #3, #32 <-- No memory access here
608ef0: f9400023 ldr x3, [x1]
608ef4: 11000400 add w0, w0, #0x1
608ef8: f822687f str xzr, [x3, x2]
608efc: 91002042 add x2, x2, #0x8
Its not available on Jenkins job anymore, but presume that its been pushed to our nightly release repo, so the Jan 6th nightly build is available from the API/webpage.
https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=openj9
Guessing this is the direct link:
https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk11u-2021-01-06-09-21/OpenJDK11U-jdk_aarch64_linux_openj9_2021-01-06-09-21.tar.gz (which can be passed into a Grinder as CUSTOMIZED_SDK_URL)
smlambert
on 12 Jan 2021
Thank you.
The failure was from a JDK8 run, and I downloaded OpenJDK8U-jdk_aarch64_linux_openj9_2021-01-07-05-03.tar.gz from the nightly build page.
This looks like an unknown problem. I don't think I have seen this before.
608ec0: b9401281 ldr w1, [x20, #16]
608ec4: b9401300 ldr w0, [x24, #16]
608ec8: 6b00003f cmp w1, w0
608ecc: 540014ec b.gt 609168 <_ZN23TR_ExceptionCheckMotion7performEv+0xa90>
608ed0: b9401682 ldr w2, [x20, #20]
608ed4: 6b03005f cmp w2, w3
608ed8: 540001cc b.gt 608f10 <_ZN23TR_ExceptionCheckMotion7performEv+0x838>
608edc: 937d7c40 sbfiz x0, x2, #3, #32
608ee0: f9400303 ldr x3, [x24]
608ee4: 11000442 add w2, w2, #0x1
608ee8: f9400284 ldr x4, [x20]
608eec: f8606861 ldr x1, [x3, x0] <-- crash here (x3=0x0FFFF00000003, x0=0x10)
608ef0: f8606884 ldr x4, [x4, x0]
608ef4: aa040021 orr x1, x1, x4
608ef8: f8206861 str x1, [x3, x0]
The crash in TR_ExceptionCheckMotion::perform is likely a dup of #11569 for which a fix is being tested.
0xdaryl
on 13 Jan 2021
Related issues
pwagland
路
3Comments
DanHeidinga
路
4Comments
pshipton
路
3Comments
Jeeppler
路
5Comments
Mesbah-Alam
路
5Comments
Most helpful comment
The crash in
TR_ExceptionCheckMotion::performis likely a dup of #11569 for which a fix is being tested.