Closed CptGit closed 11 months ago
I can reproduce it. @0xdaryl @hzongaro
Looks to be a problem in Tree Simplification. A DIVCHK
is being removed. Before:
n1n BBStart <block_2> [0x7f28da9d9210] bci=[-1,0,4] rc=0 vc=0 vn=- li=- udi=- nc=0
n8n DIVCHK [#27] [0x7f28da9d9440] bci=[-1,4,4] rc=0 vc=0 vn=- li=- udi=- nc=1
n7n ldiv [0x7f28da9d93f0] bci=[-1,4,4] rc=2 vc=0 vn=- li=- udi=- nc=2
n4n i2l [0x7f28da9d9300] bci=[-1,1,4] rc=1 vc=0 vn=- li=- udi=- nc=1
n3n iload <parm 1 I>[#352 Parm] [flags 0x40000103 0x0 ] [0x7f28da9d92b0] bci=[-1,0,4] rc=1 vc=0 vn=- li=- udi=- nc=0
n6n i2l [0x7f28da9d93a0] bci=[-1,3,4] rc=1 vc=0 vn=- li=- udi=- nc=1
n5n iload <parm 0 I>[#351 Parm] [flags 0x40000103 0x0 ] [0x7f28da9d9350] bci=[-1,2,4] rc=1 vc=0 vn=- li=- udi=- nc=0
n9n lreturn [0x7f28da9d9490] bci=[-1,5,4] rc=0 vc=0 vn=- li=- udi=- nc=1
n7n ==>ldiv
n2n BBEnd </block_2> [0x7f28da9d9260] bci=[-1,5,4] rc=0 vc=0 vn=- li=- udi=- nc=0
After
[ 1] 21.1 O^O TREE SIMPLIFICATION: Reduced ldiv [00007F28DA9D93F0] of two i2l children to i2l of idiv
n1n BBStart <block_2> [0x7f28da9d9210] bci=[-1,0,4] rc=0 vc=14 vn=- li=- udi=- nc=0
n8n treetop [0x7f28da9d9440] bci=[-1,4,4] rc=0 vc=14 vn=- li=- udi=- nc=1
n10n idiv [0x7f28da9d94e0] bci=[-1,0,4] rc=2 vc=0 vn=- li=- udi=- nc=2
n3n iload <parm 1 I>[#352 Parm] [flags 0x40000103 0x0 ] [0x7f28da9d92b0] bci=[-1,0,4] rc=1 vc=14 vn=- li=- udi=- nc=0
n5n iload <parm 0 I>[#351 Parm] [flags 0x40000103 0x0 ] [0x7f28da9d9350] bci=[-1,2,4] rc=1 vc=14 vn=- li=- udi=- nc=0
n9n lreturn [0x7f28da9d9490] bci=[-1,5,4] rc=0 vc=14 vn=- li=- udi=- nc=1
n7n i2l [0x7f28da9d93f0] bci=[-1,4,4] rc=1 vc=14 vn=- li=1 udi=- nc=1
n10n ==>idiv
n2n BBEnd </block_2> [0x7f28da9d9260] bci=[-1,5,4] rc=0 vc=14 vn=- li=- udi=- nc=0
Is divide by zero not handled as a signal on X?
Is divide by zero not handled as a signal on X?
Yes, but I believe the JIT messes up the stack map because it thinks that the division won't signal in this case. With the DIVCHK
, it produces this:
Offset info:
stackmap location: 00007FB7617FF131
map range: starting at [00007FB7639D505A]
lowOffset: 00000026
byteCodeInfo: <_callerIndex=-1, byteCodeIndex=4>, _isSameReceiver=0, _doNotProfile=0
registerSaveDescription: starting at [617FF137] { 00000000 }
registers: 00000000 { }
stack map: { }
stackmap location: 00007FB7617FF140
map range: starting at [00007FB7639D5067]
lowOffset: 00000033
byteCodeInfo: <_callerIndex=-1, byteCodeIndex=0>, _isSameReceiver=0, _doNotProfile=0
registerSaveDescription: starting at [617FF146] { 00000000 }
registers: 7FFE0000 { 17:st(0) 18:st(1) 19:st(2) 20:st(3) 21:st(4) 22:st(5) 23:st(6) 24:st(7) 25:mm0 26:mm1 27:mm2 28:mm3 29:mm4 30:mm5 }
stack map: { }
...
0x7fb7639d505a 00000026 [0x7fb762a48c80] 48 f7 f9 idiv rcx # IDIV8AccReg
...
0x7fb7639d5067 00000033 [0x7fb762a4b620] e8 34 0c 07 1c call jitStackOverflow
while without the DIVCHK
, it produces this:
Offset info:
stackmap location: 00007FF1D35FF131
map range: starting at [00007FF1FD9D5064]
lowOffset: 00000030
byteCodeInfo: <_callerIndex=-1, byteCodeIndex=0>, _isSameReceiver=0, _doNotProfile=0
registerSaveDescription: starting at [D35FF137] { 00000000 }
registers: 7FFE0000 { 17:st(0) 18:st(1) 19:st(2) 20:st(3) 21:st(4) 22:st(5) 23:st(6) 24:st(7) 25:mm0 26:mm1 27:mm2 28:mm3 29:mm4 30:mm5 }
stack map: { }
...
0x7ff1fd9d5053 0000001f [0x7ff1fca67260] f7 7c 24 18 idiv dword ptr [rsp+0x18]
...
0x7ff1fd9d5064 00000030 [0x7ff1fca69c00] e8 37 0c e7 1c call jitStackOverflow
By the way, Peter @pshipton, I don't think this needs to be included in the 0.38 milestone. It doesn't appear to be a problem that was introduced recently. I can reproduce it with a 0.27.0 build:
$ ./jdk8u302-b08/bin/java -version
openjdk version "1.8.0_302"
IBM Semeru Runtime Open Edition (build 1.8.0_302-b08)
Eclipse OpenJ9 VM (build openj9-0.27.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20210728_193 (JIT enabled, AOT enabled)
OpenJ9 - 1851b0074
OMR - 9db1c870d
JCL - de702c3174 based on jdk8u302-b08)
$ ./jdk8u302-b08/bin/java -Xjit:count=1,disableAsyncCompilation Issue17066
JVMCDRT000E Unable to locate JIT stack map - aborting VM
JVMCDRT001E Method: Issue17066.m(II)J (0000000000157388)
JVMCDRT002E Failing PC: 00007F1E52E9D91A (offset 000000000000001A), metaData = 00007F1E51060DF8
18:09:04.566 0x10bc00j9codertvm(j9ji.110 * ** ASSERTION FAILED ** at /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-x64-openj9/workspace/build/src/openj9/runtime/codert_vm/jswalk.c:538: ((0 ))
...
It seems overly simple to reproduce. If the fix is simple and low risk perhaps we can put it in 0.38.
While @hzongaro understands the problem, the fix touches a few places in the simplifier dealing with DIVCHK removal. We need to be careful here and make sure we handle each situation correctly.
A PR should be ready for 0.40, so moving to that release.
@hzongaro : should this still be targeted to 0.40? Please advise.
@0xdaryl, I have a fix ready, but I'm still working on writing unit tests to accompany it. Given that this is a long-standing problem, it's probably OK to defer it.
A revised fix for this problem is open for review. Given the complexity, I think it would be safer to defer it the 0.43 release, rather than rushing it into the 0.41 release.
System / OS / Java Runtime Information
Java version
Operating system details
Description
JVM crashed when running the following program. The bug affects 8u362, 11.0.18.0 and 17.0.6.0.
Steps to reproduce
The following steps shows how to reproduce the bug on JDK 17.0.6.0 in a Ubuntu Linux environment.
Compile
Execute
Source code for an executable test case
Workaround
Disable JIT.
Diagnostic files
See attached. diagnostic-files.zip