Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dacapo sub-benchmark "eclipse" crashes when run with large load #7452

Open
kusumachalasani opened this issue Oct 14, 2019 · 16 comments
Open

Dacapo sub-benchmark "eclipse" crashes when run with large load #7452

kusumachalasani opened this issue Oct 14, 2019 · 16 comments
Labels
arch:x86 comp:jit jdk8 os:linux prio:high userRaised
Milestone
Release 0.18 (Jav...

Comments

@kusumachalasani
Copy link

kusumachalasani commented Oct 14, 2019 •
edited
Loading

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 - fe39103
OMR - bc5ceea
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 "".

javacores.zip
@kusumachalasani
Copy link
Author

@mpirvu @vijaysun-omr FYI

@mpirvu
Copy link
Contributor

mpirvu commented Oct 14, 2019

@andrewcraik

java -Xjit:vmState=0x000536ff -version
vmState [0x536ff]: {J9VMSTATE_JIT_CODEGEN} {switchAnalyzer}

I don't know if that's correct though.

@DanHeidinga
Copy link
Member

Flagging as high priority as it's a crash

@andrewcraik
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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 eclipse-omr/omr#4450.

@lumpfish lumpfish mentioned this issue Oct 17, 2019
Closed
39 tasks
@DanHeidinga DanHeidinga added the backport:candidate Possible candidate for a backport to a `0.x.y+1` release label Oct 17, 2019
@andrewcraik
Copy link
Contributor

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.

@pshipton pshipton removed the backport:candidate Possible candidate for a backport to a `0.x.y+1` release label Mar 12, 2020
@smlambert
Copy link
Contributor

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 smlambert reopened this Jan 8, 2021
@pshipton
Copy link
Member

pshipton commented Jan 8, 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.

@fjeremic fjeremic changed the title Dacapo sub-benchmark "eclipse" crashes when run with large load. Dacapo sub-benchmark "eclipse" crashes when run with large load Jan 11, 2021
@knn-k
Copy link
Contributor

knn-k commented Jan 12, 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
Copy link
Contributor

knn-k commented Jan 12, 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]

@smlambert
Copy link
Contributor

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:
Screen Shot 2021-01-11 at 11 23 02 PM

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=

@knn-k
Copy link
Contributor

knn-k commented Jan 12, 2021

@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

@smlambert
Copy link
Contributor

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

Screen Shot 2021-01-12 at 10 43 29 AM

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)

@knn-k
Copy link
Contributor

knn-k commented Jan 13, 2021 •
edited
Loading

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]

@0xdaryl
Copy link
Contributor

0xdaryl commented Jan 13, 2021 •
edited
Loading

The crash in TR_ExceptionCheckMotion::perform is likely a dup of #11569 for which a fix is being tested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arch:x86 comp:jit jdk8 os:linux prio:high userRaised
Projects
None yet
Milestone
Release 0.18 (Java 8, 11, 13) Jan ref...
Development

No branches or pull requests
8 participants
@smlambert @andrewcraik @DanHeidinga @0xdaryl @kusumachalasani @pshipton @mpirvu @knn-k