DanHeidinga
commented
2 years ago fyi @0xdaryl
Closed lochnagarr closed 2 years ago
DanHeidinga
commented
2 years ago fyi @0xdaryl
hzongaro
commented
2 years ago Annabelle @a7ehuo, may I ask you to take a look at this crash?
a7ehuo
commented
2 years ago The crashed happened in TR_OrderBlocks::peepHoleBranchBlock because the next treetop of the BBEnd of block_924 is NULL. block_924 is created in generalLoopUnroller. Setting disableGLU also makes the crash go away. Interestingly block_918 is also cloned in generalLoopUnroller but the next treetop for its BBEnd looks good.
The crash seems consistently happen when compiling org/apache/commons/text/numbers/ParsedDecimal.prepareOutput(I)V. However, if I add tracing on this method, the crash goes away. I'll instrument the code and see if I can catch the issue in an early stage of the optimization.
#12 <signal handler called>
#13 0x00007fb2acd0e3f6 in TR_OrderBlocks::peepHoleBranchBlock (this=this@entry=0x7fb28c35b630,
cfg=cfg@entry=0x7fb287020000, block=block@entry=0x7fb287712df0, title=title@entry=0x7fb2ad03bb00 "O^O ORDER BLOCKS: ")
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OrderBlocks.cpp:1339
#14 0x00007fb2acd12c41 in TR_OrderBlocks::doPeepHoleBlockCorrections (this=this@entry=0x7fb28c35b630,
block=block@entry=0x7fb287712df0, title=title@entry=0x7fb2ad03bb00 "O^O ORDER BLOCKS: ")
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OrderBlocks.cpp:1550
#15 0x00007fb2acd12e68 in TR_OrderBlocks::lookForPeepHoleOpportunities (this=0x7fb28c35b630,
title=0x7fb2ad03bb00 "O^O ORDER BLOCKS: ")
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OrderBlocks.cpp:1589
#16 0x00007fb2acd12ffd in TR_OrderBlocks::doReordering (this=this@entry=0x7fb28c35b630)
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OrderBlocks.cpp:2078
#17 0x00007fb2acd132b8 in TR_OrderBlocks::perform (this=this@entry=0x7fb28c35b630)
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OrderBlocks.cpp:2125
#18 0x00007fb2accf552a in TR_ExtendBasicBlocks::perform (this=<optimized out>)
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/LocalOpts.cpp:176
#19 0x00007fb2acd048c7 in OMR::Optimizer::performOptimization (this=this@entry=0x7fb2870f38a0,
optimization=optimization@entry=0x7fb2ad03b3d8 <blockManipulationOpts+56>, firstOptIndex=firstOptIndex@entry=0,
--Type <RET> for more, q to quit, c to continue without paging--
lastOptIndex=lastOptIndex@entry=2147483647, doTiming=doTiming@entry=0)
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OMROptimizer.cpp:2053
...
(gdb) fr 13
#13 0x00007fb2acd0e3f6 in TR_OrderBlocks::peepHoleBranchBlock (this=this@entry=0x7fb28c35b630,
cfg=cfg@entry=0x7fb287020000, block=block@entry=0x7fb287712df0, title=title@entry=0x7fb2ad03bb00 "O^O ORDER BLOCKS: ")
at /root/home/ahuo/src/openj9-openjdk-jdk11/omr/compiler/optimizer/OrderBlocks.cpp:1339
1339 TR::Block *fallThroughBlock = fallThroughEntry->getNode()->getBlock();(gdb) print *block
$1 = {<OMR::Block> = {<TR::CFGNode> = {<TR_Link1<TR::CFGNode>> = {_next = 0x7fb287712b30, _valid = true},
_vptr.CFGNode = 0x7fb2ad3bdc98 <vtable for TR::Block+16>, _region = @0x7fb28c361950, _successors = {_head = {
_next = 0x7fb2877149e0}, _allocator = {<TR::typed_allocator<void, TR::Region&>> = {
_backingAllocator = @0x7fb28c361950}, <No data fields>}}, _predecessors = {_head = {_next = 0x7fb287713800},
_allocator = {<TR::typed_allocator<void, TR::Region&>> = {_backingAllocator = @0x7fb28c361950}, <No data fields>}},
_exceptionSuccessors = {_head = {_next = 0x0}, _allocator = {<TR::typed_allocator<void, TR::Region&>> = {
_backingAllocator = @0x7fb28c361950}, <No data fields>}}, _exceptionPredecessors = {_head = {_next = 0x0},
_allocator = {<TR::typed_allocator<void, TR::Region&>> = {_backingAllocator = @0x7fb28c361950}, <No data fields>}},
_nodeNumber = 924, _visitCount = 16732, _frequency = 0, _forwardTraversalIndex = 565, _backwardTraversalIndex = 9},
static _standardExceptions = {{length = 5, name = 0x7fb2acfa214d "Error", exceptions = 4288}, {length = 9,
name = 0x7fb2acf8df15 "Exception", exceptions = 445}, {length = 9, name = 0x7fb2acfa7167 "Throwable",
exceptions = 8191}, {length = 12, name = 0x7fb2ad0191df "UnknownError", exceptions = 4288}, {length = 13,
name = 0x7fb2ad0191ec "InternalError", exceptions = 4288}, {length = 16, name = 0x7fb2ad0191fa "OutOfMemoryError",
exceptions = 4288}, {length = 16, name = 0x7fb2ad01920b "RuntimeException", exceptions = 445}, {length = 18,
name = 0x7fb2ad055e42 "ClassCastException", exceptions = 32}, {length = 18,
name = 0x7fb2ad01921c "IllegalAccessError", exceptions = 4224}, {length = 18,
name = 0x7fb2ad01922f "InstantiationError", exceptions = 4160}, {length = 18,
name = 0x7fb2ad019242 "StackOverflowError", exceptions = 4288}, {length = 19,
name = 0x7fb2ad055c2c "ArithmeticException", exceptions = 4}, {length = 19,
name = 0x7fb2ad055c48 "ArrayStoreException", exceptions = 16}, {length = 19,
name = 0x7fb2ad019255 "VirtualMachineError", exceptions = 4288}, {length = 20,
name = 0x7fb2ad055bf1 "NullPointerException", exceptions = 1}, {length = 25,
name = 0x7fb2ad019269 "IndexOutOfBoundsException", exceptions = 8}, {length = 26,
name = 0x7fb2ad019283 "NegativeArraySizeException", exceptions = 128}, {length = 28,
name = 0x7fb2ad01929e "IllegalMonitorStateException", exceptions = 256}, {length = 28,
name = 0x7fb2ad0192bb "IncompatibleClassChangeError", exceptions = 4288}, {length = 30,
name = 0x7fb2ad0196e8 "ArrayIndexOutOfBoundsException", exceptions = 8}, {length = 99, name = 0x7fb2acf94b94 "",
exceptions = 0}}, _pEntry = 0x7fb287712db0, _pExit = 0x7fb287712dd0, _liveLocals = 0x0, _pStructureOf =
0x7fb2877fdba0, _globalRegisters = 0x0,
_instructionBoundaries = {<TR_Link<OMR::Block::InstructionBoundaries>> = {<TR_Link0<OMR::Block::InstructionBoundaries>> = {_next = 0x0}, <No data fields>}, _startPC = 4294967295, _endPC = 4294967295},
_snippetBoundaries = {<TR_LinkHead0<OMR::Block::InstructionBoundaries>> = {_head = 0x0}, <No data fields>},
_firstInstruction = 0x0, _lastInstruction = 0x0, _catchBlockExtension = 0x0, _unrollFactor = 0, _blockSize = -1,
_blockBCIndex = 0, _j9EstimateSizeMethod = 0x0, _debugCounters = 0x0, _flags = {_flags = 0}, _moreflags = {
_flags = 0}}, <No data fields>}
(gdb) p block->_pExit
$2 = (TR::TreeTop *) 0x7fb287712dd0
// BBEnd of block_924
(gdb) p block->_pExit->_pNode->_globalIndex
$6 = 7297
(gdb) p block->_pExit->_pNext
$4 = (TR::TreeTop *) 0x0
// BBEnd of block_918
(gdb) p block->_pEntry->_pPrev->_pNode->_globalIndex
$1 = 7247
(gdb) p block->_pEntry->_pPrev->_pNext->_pNode->_globalIndex
$2 = 7293
[ 2117] O^O GENERAL LOOP UNROLLER: Unrolling non-counted loop 422 [unrollfactor:4, peelcount:0]
(Invalidating structure)
BLOCK CLONER: Newly created block_918 is a clone of original block_418
...
BLOCK CLONER: Newly created block_924 is a clone of original block_418
...
BLOCK CLONER: Newly created block_930 is a clone of original block_418n7243n BBStart <block_918> (freq 0) (in loop 422) [0x7fb23b1fc7b0] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
n7244n ificmpeq --> block_206 BBStart at n1679n () [0x7fb23b1fc800] bci=[-1,213,508] rc=0 vc=16944 vn=- li=- udi=- nc=2 flg=0x20
n7245n iload <auto slot 12>[#401 Auto] [flags 0x3 0x0 ] [0x7fb23b1fc850] bci=[-1,210,508] rc=1 vc=16944 vn=- li=- udi=366 nc=0
n7246n iconst 1 [0x7fb23b1fc8a0] bci=[-1,212,508] rc=1 vc=16944 vn=- li=- udi=- nc=0
n7247n BBEnd </block_918> ===== [0x7fb23b1fc8f0] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
n7293n BBStart <block_924> (freq 0) (in loop 422) [0x7fb23b1fd750] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
n7294n ificmpeq --> block_206 BBStart at n1679n () [0x7fb23b1fd7a0] bci=[-1,213,508] rc=0 vc=16944 vn=- li=- udi=- nc=2 flg=0x20
n7295n iload <auto slot 12>[#401 Auto] [flags 0x3 0x0 ] [0x7fb23b1fd7f0] bci=[-1,210,508] rc=1 vc=16944 vn=- li=- udi=366 nc=0
n7296n iconst 1 [0x7fb23b1fd840] bci=[-1,212,508] rc=1 vc=16944 vn=- li=- udi=- nc=0
n7297n BBEnd </block_924> ===== [0x7fb23b1fd890] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
n7343n BBStart <block_930> (freq 0) (in loop 422) [0x7fb23b1fe6f0] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
n7344n ificmpeq --> block_206 BBStart at n1679n () [0x7fb23b1fe740] bci=[-1,213,508] rc=0 vc=16944 vn=- li=- udi=- nc=2 flg=0x20
n7345n iload <auto slot 12>[#401 Auto] [flags 0x3 0x0 ] [0x7fb23b1fe790] bci=[-1,210,508] rc=1 vc=16944 vn=- li=- udi=366 nc=0
n7346n iconst 1 [0x7fb23b1fe7e0] bci=[-1,212,508] rc=1 vc=16944 vn=- li=- udi=- nc=0
n7347n BBEnd </block_930> ===== [0x7fb23b1fe830] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
Narrowing down the issue more: the next tree top of the BBEnd n7297n for block_924 is removed in TR_BlockOrderingOptimization::connectTreesAccordingToOrder. Looks like block_924 is moved to the end of tree top list after connectTreesAccordingToOrder. I suspect either TR_OrderBlocks::peepHoleBranchBlock should have checked if fallThroughEntry is NULL or not because there is always a chance the block is the last block, or TR_OrderBlocks::peepHoleBranchBlock should not be called on the block whose exit node doesn't have a successor.
DEBUG START after generateNewOrder: for org/apache/commons/text/numbers/ParsedDecimal.prepareOutput(I)V
...
n7297n BBEnd </block_924> (DEBUG fallThroughEntry 0x7ff1a3380728 n7343n) ===== [0x7ff1a331d890] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
...DEBUG START after connectTreesAccordingToOrder: for org/apache/commons/text/numbers/ParsedDecimal.prepareOutput(I)V
...
n7297n BBEnd </block_924> (DEBUG fallThroughEntry (nil) n-1n) [0x7ff1a331d890] bci=[-1,268,508] rc=0 vc=16944 vn=- li=- udi=- nc=0
...The root cause of the crash is that the edges of the cloned blocks in general unroller are not set up correctly in addEdgeAndFixEverything. Running verifyCFG confirms the issue. The crash from this test happens only when the EdgeContext is BackEdgeToEntry.
Use block_918 as an example, it's a clone of block_418. After GLU, it should have edges to block_206 and block_422. block_422 is not a fall through block for block_918. A goto block is required after block_918 to jump back to block_422.
jitdump.20220831.094334.4138.0004.oneIteration.CFGVerify.dmp.zip
CFG Before GLU
422: in=[836 421 418] out=[421 420] // 418 -> 422
421: in=[422] out=[417 422]
417: in=[421] out=[420]
420: in=[422 417] out=[418]
418: in=[420] out=[206 422] // 418 -> 422
CFG After GLU
422: in=[918 921 836 418] out=[421 420] // 418 -> 422, 918 -> 422
...
418: in=[420] out=[206 422] // 418 -> 422
...
918: in=[919] out=[206 422] // 918 -> 422Tree after GLU
n3367n BBStart <block_413> (freq 6) (in loop 10) [0x7fec6fc10c30] bci=[-1,256,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n3369n goto --> block_250 BBStart at n2184n [0x7fec6fc10cd0] bci=[-1,256,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n3368n BBEnd </block_413> (fallThroughEntry 0x7fec6e815e38 n7243n) ===== [0x7fec6fc10c80] bci=[-1,256,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n7243n BBStart <block_918> (freq 0) (in loop 422) [0x7fec6e2bc7b0] bci=[-1,268,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n7244n ificmpeq --> block_206 BBStart at n1679n () [0x7fec6e2bc800] bci=[-1,213,508] rc=0 vc=16254 vn=- li=- udi=- nc=2 flg=0x20
n7245n iload <auto slot 12>[#401 Auto] [flags 0x3 0x0 ] [0x7fec6e2bc850] bci=[-1,210,508] rc=1 vc=16254 vn=- li=- udi=366 nc=0
n7246n iconst 1 [0x7fec6e2bc8a0] bci=[-1,212,508] rc=1 vc=16254 vn=- li=- udi=- nc=0
n7247n BBEnd </block_918> (fallThroughEntry 0x7fec6fbddc48 n3397n) ===== [0x7fec6e2bc8f0] bci=[-1,268,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n3397n BBStart <block_418> (freq 0) (in loop 422) [0x7fec6fc11590] bci=[-1,268,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n3399n ificmpeq --> block_206 BBStart at n1679n () [0x7fec6fc11630] bci=[-1,213,508] rc=0 vc=16254 vn=- li=- udi=- nc=2 flg=0x20
n3400n iload <auto slot 12>[#401 Auto] [flags 0x3 0x0 ] [0x7fec6fc11680] bci=[-1,210,508] rc=1 vc=16254 vn=- li=- udi=366 nc=0
n3401n iconst 1 [0x7fec6fc116d0] bci=[-1,212,508] rc=1 vc=16254 vn=- li=- udi=- nc=0
n3398n BBEnd </block_418> (fallThroughEntry 0x7fec6fbde1c8 n3425n) ===== [0x7fec6fc115e0] bci=[-1,268,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n3425n BBStart <block_422> (freq 7099) (in loop 422)
...
...
n7248n BBStart <block_919> (freq 477) (in loop 422) [0x7fec6e2bc940] bci=[-1,268,508] rc=0 vc=16213 vn=- li=- udi=- nc=0
n7249n asynccheck jitCheckAsyncMessages[#23 helper Method] [flags 0x400 0x0 ] [0x7fec6e2bc990] bci=[-1,268,508] rc=0 vc=16254 vn=- li=- udi=- nc=0
n7250n ificmple --> block_918 BBStart at n7243n (maxLoopIternGuard )
... BLOCK CLONER: Newly created block_918 is a clone of original block_418
...
unrollLoopOnce: Type C finalUnroll 1 _iteration 1 _unrollKind 5 CompleteUnroll 1 edge: block_418 -> block_422
>>>--------------------------------------
addEdgeAndFixEverything: fromNode (block_418 -> block_422) newFromNode (block_918 -> block_422) redirectOriginal 0 removeOriginalEdges 0 edgeToEntry 1 context 2
addEdgeAndFixEverything: fromNode: (block_418 -> block_422) newFromNode: (block_918 -> block_422) from (block_418 -> block_422) newFrom (block_918 -> block_422). lastNode n3399n isBranch 1 getBranchDestination n1679n to->getEntry() n3425n
addEdgeAndFixEverything: FALLS INTO: newFromNextBlock block_922 != newTo block_422 from (block_418 -> block_422) newFrom (block_918 -> block_422) swingBlocks
addEdgeAndFixEverything: FALLS INTO: createEdge newFromNode (block_918 -> block_422)
addEdgeAndFixEverything: FALLS INTO: addEdge newFrom (block_918 -> block_422)
addEdgeAndFixEverything: fromNode (block_418 -> block_422) newFromNode (block_918 -> block_422) redirectOriginal 0 removeOriginalEdges 0 edgeToEntry 1 context 2
<<<--------------------------------------
...
...
++++++ verifyCFG +++++
Successor block [422] of block [918] containing a branch does not match the destination(s) specified in the IL branch instruction
block_918 (edge block_918 -> block_422) next block_422 fallThroughBlock block_418 branchBlock block_206
Check for correctness of successors is NOT successful
The CFG is NOT correct
Printing out the CFG from CFGCheckerWhen running a buggy classfile generated by a fuzzer
@lochnagarr Could you elaborate more on what kind of buggy classfile it is referred here? What is the issue with the classfile? I'm trying to understand more of what the test does to assess the fix since the code that's involved hasn't been changed for a long time
Since the crash happened with org/apache/commons/text/numbers/ParsedDecimal.prepareOutput(I)V, I'm especially interested in whether this method might be modified by the fuzzer?
lochnagarr
commented
2 years ago When running a buggy classfile generated by a fuzzer
@lochnagarr Could you elaborate more on what kind of buggy classfile it is referred here? What is the issue with the classfile? I'm trying to understand more of what the test does to assess the fix since the code that's involved hasn't been changed for a long time
Since the crash happened with
org/apache/commons/text/numbers/ParsedDecimal.prepareOutput(I)V, I'm especially interested in whether this method might be modified by the fuzzer?
Hi @a7ehuo
Yes, the method org/apache/commons/text/numbers/ParsedDecimal.prepareOutput(I)V is modified by the fuzzer. My apology for not being able to provide more information, because this file is generated randomly with complicated transformations.
a7ehuo
commented
2 years ago I found out a bit more on why this issue happens so far only with the fuzzer modified classfile but not with our existing test suites. The existing implementation of TR_LoopUnroller::addEdgeAndFixEverything relies on swingBlocks to swing the block to the right order in the fall through case. In normal circumstances (our existing test suites), swingBlocks works correctly. It doesn't work with the modified classefile because there are more than one block needs to swing to be before block_422 [1]. After processSwingBlocks, only block_418 falls through to block_422. block_918, block_924, and block_930 no longer fall through to block_422 after each swing. The normal circumstances or our existing test suites do not have this issue because there is never more than one block that needs to fall through to the same block.
With this finding, I need to think of the fix again. Adding goto blocks fix the issue but I wonder if it's over doing it for the normal cases. I also need to understand if having multiple blocks fall through to the same block is the desired design or if some other part of the code is not functioning correctly
[1]
processSwingBlocks: (from->to)(block_918 -> block_422): pF block_915 pT block_418 nF block_922 nT block_421
processSwingBlocks: (from->to)(block_924 -> block_422): pF block_923 pT block_918 nF block_928 nT block_421
processSwingBlocks: (from->to)(block_930 -> block_422): pF block_929 pT block_924 nF block_934 nT block_421
processSwingBlocks: (from->to)(block_418 -> block_422): pF block_413 pT block_930 nF block_918 nT block_421@pshipton @0xdaryl With the above finding, our existing test suites do not have this issue and the issue is not new. More time is needed to assess the fix. I wonder if we should move this issue out of 0.35 release
a7ehuo
commented
2 years ago After some offline discussion with @jdmpapin, I'd like to clarify this issue a bit more. block_918, block_924, and block_930 are a clone of block_418. The loop entry is block_422. block_422 is a fall through of block_418. block_918, block_924, and block_930 all need to get to block_422. "goto" blocks are required so that these blocks can jump to block_422. The uniqueness about this test is that addEdgeAndFixEverything might have not expected the loop entry block block_422 is a fall through of the original block block_418 and multiple cloned blocks need to jump to it. That might be why it didn't handle this case properly. Running verifyCFG clearly shows the edges between these blocks are messed up due to the missing goto blocks. This is not a common case in our existing test suites. I also found addExitEdgeAndFixEverything already handles the similar case by adding goto blocks, which is what's done in the fix #6693 for addEdgeAndFixEverything.
BLOCK CLONER: Newly created block_918 is a clone of original block_418
...
BLOCK CLONER: Newly created block_924 is a clone of original block_418
...
BLOCK CLONER: Newly created block_930 is a clone of original block_418`Before GLU
n3397n BBStart <block_418> (freq 0) (in loop 422) [0x7fc904f51590] bci=[-1,268,508] rc=0 vc=15950 vn=- li=- udi=- nc=0
n3399n ificmpeq --> block_206 BBStart at n1679n () [0x7fc904f51630] bci=[-1,213,508] rc=0 vc=15950 vn=- li=- udi=- nc=2 flg=0x20
n3400n iload <auto slot 12>[#437 Auto] [flags 0x3 0x0 ] [0x7fc904f51680] bci=[-1,210,508] rc=1 vc=15950 vn=- li=- udi=366 nc=0
n3401n iconst 1 [0x7fc904f516d0] bci=[-1,212,508] rc=1 vc=15950 vn=- li=- udi=- nc=0
n3398n BBEnd </block_418> ===== [0x7fc904f515e0] bci=[-1,268,508] rc=0 vc=15950 vn=- li=- udi=- nc=0
n3425n BBStart <block_422> (freq 7099) (in loop 422)
Java -version output
openjdk version "1.8.0_345" IBM Semeru Runtime Open Edition (build 1.8.0_345-b01) Eclipse OpenJ9 VM (build openj9-0.33.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20220805_444 (JIT enabled, AOT enabled) OpenJ9 - 04a55b45b OMR - b58aa2708 JCL - f2d89babf5 based on jdk8u345-b01)
openjdk version "11.0.16" 2022-07-19 IBM Semeru Runtime Open Edition 11.0.16.0 (build 11.0.16+8) Eclipse OpenJ9 VM 11.0.16.0 (build openj9-0.33.0, JRE 11 Linux amd64-64-Bit Compressed References 20220804_491 (JIT enabled, AOT enabled) OpenJ9 - 04a55b45b OMR - b58aa2708 JCL - ab74d97849 based on jdk-11.0.16+8)
openjdk version "17.0.4" 2022-07-19 IBM Semeru Runtime Open Edition 17.0.4.0 (build 17.0.4+8) Eclipse OpenJ9 VM 17.0.4.0 (build openj9-0.33.0, JRE 17 Linux amd64-64-Bit Compressed References 20220719_256 (JIT enabled, AOT enabled) OpenJ9 - 04a55b45b OMR - b58aa2708 JCL - d680e266ef4 based on jdk-17.0.4+8)
OS version
Distributor ID: Ubuntu Description: Ubuntu 22.04 LTS Release: 22.04 Codename: jammy
Summary of problem
When running a buggy classfile generated by a fuzzer (with jit enabled), we get the following error message:
Note that Openj9 runs with jit enabled. Particularly, setingt
optleveltohotor higher (with jvm option-Xjit:optlevel=hot) will trigger this issue, whilewarmor lower will not.Diagnostic files
javacore.20220822.144314.1583749.0002.txt bug_jit.zip
How to Reproduce
Note that when
optlevelisnoOpt,coldandwarm, there is no problem. whenoptlevelishot,veryHotandscorching, it will produce such error message.