JDK-8240905 : assert(mem == (Node*)1 || mem == mem2) failed: multiple Memories being matched at once?
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u241,11,12,13,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-03-11
  • Updated: 2023-09-29
  • Resolved: 2020-03-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15
11.0.8-oracleFixed 13.0.4Fixed 15 b16Fixed
Related Reports
Duplicate :  
Description
Generated test crashed with
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/opto/matcher.cpp:1785), pid=29345, tid=29357
#  assert(mem == (Node*)1 || mem == mem2) failed: multiple Memories being matched at once?
#
# JRE version: Java(TM) SE Runtime Environment (15.0+13) (fastdebug build 15-ea+13-487)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-ea+13-487, compiled mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1109778]  Matcher::ReduceInst_Interior(State*, int, Node*&, MachNode*, unsigned int)+0x3d8
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /tmp/fuzzer.tmp.vs6e5d5ce2/core.29345)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test Test

Host: AMD EPYC 7551 32-Core Processor, 16 cores, 62G, Oracle Linux Server release 7.7
Time: Mon Mar  9 06:07:43 2020 GMT elapsed time: 2 seconds (0d 0h 0m 2s)

---------------  T H R E A D  ---------------

Current thread (0x00007fa6e853c800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=29357, stack(0x00007fa6c0711000,0x00007fa6c0812000)]


Current CompileTask:
C2:   2518   16   !b  4       Test::mainTest (855 bytes)

Stack: [0x00007fa6c0711000,0x00007fa6c0812000],  sp=0x00007fa6c080cb00,  free space=1006k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1109778]  Matcher::ReduceInst_Interior(State*, int, Node*&, MachNode*, unsigned int)+0x3d8
V  [libjvm.so+0x11095fd]  Matcher::ReduceInst_Interior(State*, int, Node*&, MachNode*, unsigned int)+0x25d
V  [libjvm.so+0x1109c88]  Matcher::ReduceInst(State*, int, Node*&)+0x4d8
V  [libjvm.so+0x110e859]  Matcher::match_tree(Node const*)+0x329
V  [libjvm.so+0x1111da1]  Matcher::xform(Node*, int)+0xc51
V  [libjvm.so+0x1115fa5]  Matcher::match()+0xd05
V  [libjvm.so+0x86a224]  Compile::Code_Gen()+0x84
V  [libjvm.so+0x86e561]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1171
V  [libjvm.so+0x6dc6b0]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x110
V  [libjvm.so+0x87afac]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2cc
V  [libjvm.so+0x87bf48]  CompileBroker::compiler_thread_loop()+0x458
V  [libjvm.so+0x152f356]  JavaThread::thread_main_inner()+0x226
V  [libjvm.so+0x15343d6]  Thread::call_run()+0xf6
V  [libjvm.so+0x1265a36]  thread_native_entry(Thread*)+0x116

Register to memory mapping:

RAX=0x00007fa6f2603000 points into unknown readable memory: 58 00 00 00 00 00 00 00
RBX=0x00007fa69c1879b0 points into unknown readable memory: c8 50 85 f1 a6 7f 00 00
RCX=0x00007fa6f1510c70: <offset 0x00000000017d9c70> in /home/lmesnik/jenkins/workspace/JavaFuzzer/jdk/lib/server/libjvm.so at 0x00007fa6efd37000
RDX=0x00007fa6f1510d18: <offset 0x00000000017d9d18> in /home/lmesnik/jenkins/workspace/JavaFuzzer/jdk/lib/server/libjvm.so at 0x00007fa6efd37000
RSP=0x00007fa6c080cb00 is pointing into the stack for thread: 0x00007fa6e853c800
RBP=0x00007fa6c080cb80 is pointing into the stack for thread: 0x00007fa6e853c800
RSI=0x00000000000006f9 is an unknown value
RDI=0x00007fa6f1510a50: <offset 0x00000000017d9a50> in /home/lmesnik/jenkins/workspace/JavaFuzzer/jdk/lib/server/libjvm.so at 0x00007fa6efd37000
R8 =0x00007fa69c1879b0 points into unknown readable memory: c8 50 85 f1 a6 7f 00 00
R9 =0x0000000000000003 is an unknown value
R10=0x0000000000000200 is an unknown value
R11=0x00007fa69c5d1928 points into unknown readable memory: 40 a7 8a f1 a6 7f 00 00
R12=0x00007fa69c5d1460 points into unknown readable memory: 08 d6 8c f1 a6 7f 00 00
R13=0x00007fa69c02bbc0 points into unknown readable memory: 20 8d 8c f1 a6 7f 00 00
R14=0x00007fa6c080e090 is pointing into the stack for thread: 0x00007fa6e853c800
R15=0x00007fa6c080ccb8 is pointing into the stack for thread: 0x00007fa6e853c800


Registers:
RAX=0x00007fa6f2603000, RBX=0x00007fa69c1879b0, RCX=0x00007fa6f1510c70, RDX=0x00007fa6f1510d18
RSP=0x00007fa6c080cb00, RBP=0x00007fa6c080cb80, RSI=0x00000000000006f9, RDI=0x00007fa6f1510a50
R8 =0x00007fa69c1879b0, R9 =0x0000000000000003, R10=0x0000000000000200, R11=0x00007fa69c5d1928
R12=0x00007fa69c5d1460, R13=0x00007fa69c02bbc0, R14=0x00007fa6c080e090, R15=0x00007fa6c080ccb8
RIP=0x00007fa6f0e40778, EFLAGS=0x0000000000010206, CSGSFS=0x002b000000000033, ERR=0x0000000000000006
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007fa6c080cb00)
0x00007fa6c080cb00:   00007fa6c080cb30 00000009f068ef13
0x00007fa6c080cb10:   0000000000000008 00007fa69c187a20
0x00007fa6c080cb20:   0000000000000002 00007fa600000003
0x00007fa6c080cb30:   00007fa6c080ccb8 0000000000000094 

Instructions: (pc=0x00007fa6f0e40778)
0x00007fa6f0e40678:   c7 08 e8 c1 bf ff ff 31 f6 48 89 df 48 89 c2 e8
0x00007fa6f0e40688:   d4 a3 2c ff e9 10 fe ff ff 0f 1f 80 00 00 00 00
0x00007fa6f0e40698:   45 89 c1 41 8d 40 01 48 89 df 89 55 8c 49 c1 e1
0x00007fa6f0e406a8:   03 89 45 a0 4c 89 c9 49 03 4c 24 60 4c 89 4d 90
0x00007fa6f0e406b8:   48 89 4d 98 e8 4f 4a 33 ff 48 8b 4d 98 8b 55 8c
0x00007fa6f0e406c8:   4d 89 e0 48 89 de 4c 89 f7 48 89 01 48 8b 4d b0
0x00007fa6f0e406d8:   e8 23 f8 ff ff 44 8b 45 a0 4c 8b 4d 90 e9 ab fe
0x00007fa6f0e406e8:   ff ff 66 0f 1f 44 00 00 48 8d 05 e1 be a9 00 45
0x00007fa6f0e406f8:   31 c0 48 8d 0d c8 8b 73 00 48 8d 15 d4 8b 73 00
0x00007fa6f0e40708:   be 74 01 00 00 48 8d 3d 5c 7b 5e 00 48 8b 00 c6
0x00007fa6f0e40718:   00 58 45 8b 4c 24 1c 31 c0 e8 ca e9 7b ff e8 a5
0x00007fa6f0e40728:   3b 15 00 e9 58 fd ff ff 49 8d 74 24 1c 49 8d 7c
0x00007fa6f0e40738:   24 08 e8 51 c0 ff ff 4c 8b 7d b0 49 89 c4 49 8b
0x00007fa6f0e40748:   07 4c 39 e0 74 3c 48 83 f8 01 74 36 48 8d 05 7d
0x00007fa6f0e40758:   be a9 00 48 8d 0d 0e 05 6d 00 48 8d 15 af 05 6d
0x00007fa6f0e40768:   00 be f9 06 00 00 48 8d 3d db 02 6d 00 48 8b 00
0x00007fa6f0e40778:   c6 00 58 31 c0 e8 6e e9 7b ff e8 49 3b 15 00 49
0x00007fa6f0e40788:   8b 07 48 83 f8 01 74 10 48 8b 45 b0 4c 89 20 4d
0x00007fa6f0e40798:   8b 65 20 e9 db fc ff ff 49 8b 45 20 49 89 86 a0
0x00007fa6f0e407a8:   0b 00 00 eb e3 90 66 90 55 48 89 e5 41 57 49 89
0x00007fa6f0e407b8:   f7 41 56 41 89 d6 41 55 41 54 49 89 fc 53 48 83
0x00007fa6f0e407c8:   ec 28 48 89 4d c8 83 fa 7e 7e 2d 49 8b 77 20 44
0x00007fa6f0e407d8:   89 f2 4c 89 e7 e8 1e f4 ff ff 49 89 c5 48 85 c0
0x00007fa6f0e407e8:   74 4e 48 83 c4 28 4c 89 e8 5b 41 5c 41 5d 41 5e
0x00007fa6f0e407f8:   41 5f 5d c3 0f 1f 40 00 48 8d 05 d1 bd a9 00 48
0x00007fa6f0e40808:   8d 0d 38 a7 77 00 48 8d 15 4a a7 77 00 be 5b 06
0x00007fa6f0e40818:   00 00 48 8d 3d 2f 02 6d 00 48 8b 00 c6 00 58 31
0x00007fa6f0e40828:   c0 e8 c2 e8 7b ff e8 9d 3a 15 00 eb 9e 0f 1f 00
0x00007fa6f0e40838:   44 89 f6 4c 89 ff e8 ad 8b 33 ff 48 89 c3 48 85
0x00007fa6f0e40848:   c0 0f 84 f1 05 00 00 49 8b 94 24 a0 0a 00 00 49
0x00007fa6f0e40858:   63 c6 4c 8b 6b 60 4c 89 ff 8b 34 82 e8 a7 48 33
0x00007fa6f0e40868:   ff 49 89 45 00 48 8b 43 60 48 83 38 00 0f 84 85 


Stack slot to memory mapping:
stack at sp + 0 slots: 0x00007fa6c080cb30 is pointing into the stack for thread: 0x00007fa6e853c800
stack at sp + 1 slots: 0x00000009f068ef13 is an unknown value
stack at sp + 2 slots: 0x0000000000000008 is an unknown value
stack at sp + 3 slots: 0x00007fa69c187a20 points into unknown readable memory: 70 7a 18 9c a6 7f 00 00
stack at sp + 4 slots: 0x0000000000000002 is an unknown value
stack at sp + 5 slots: 0x00007fa600000003 is an unknown value
stack at sp + 6 slots: 0x00007fa6c080ccb8 is pointing into the stack for thread: 0x00007fa6e853c800
stack at sp + 7 slots: 0x0000000000000094 is an unknown value


Comments
Fix request (13u): The original change applies cleanly, tier1 tests pass.
05-06-2020

Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.8-oracle. Applies clean.
14-04-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/23dab0354eb0 User: thartmann Date: 2020-03-24 16:39:50 +0000
24-03-2020

Since JDK-8031321 which added support for Intel's bit manipulation instructions to JDK 8u20, we have rules in the .ad file that are matching two LoadNodes and therefore two memory inputs to a single instruction (for example, blsiI_rReg_mem [1]). As of today, these BMI1 instructions are still the only ones that match multiple memory. Since the matcher does not match memory edges, it can happen that the memory inputs of the LoadNodes differ and we hit the reported assert. For example, with volatile field accesses, a MemBarAcquire is added between the first and the second LoadNode (see test_blsiI_rReg_mem_2). With a product build, we would simply ignore the inconsistent memory inputs and match to a 'blsi'. I think this would break the happens-before guarantee of volatile memory accesses because the first load is effectively re-ordered with the volatile access. We already have checks in Matcher::Label_Root() that stop recursion when the memory differs (see [2] and [3]) but these only work if the LoadNodes have the same depth in the tree. I propose to strengthen these checks and stop recursion if there are multiple loads with different memory inputs in the tree. Since that code is using a breadth-first-search, the depth of the first load (which will be part of the tree) is always <= the depth of the offending load (which will not be part of the tree and is matched into a register). Now I think this could still lead to different match results but I couldn't come up with an example where an existing match rule is affected. http://cr.openjdk.java.net/~thartmann/8240905/webrev.00/ [1] http://hg.openjdk.java.net/jdk/jdk/file/89ec93d09e7e/src/hotspot/cpu/x86/x86_64.ad#l9480 [2] http://hg.openjdk.java.net/jdk/jdk/file/89ec93d09e7e/src/hotspot/share/opto/matcher.cpp#l1489 [3] http://hg.openjdk.java.net/jdk/jdk/file/89ec93d09e7e/src/hotspot/share/opto/matcher.cpp#l1525
20-03-2020

JDK-8211233 just triggers the issue. With a slightly adjusted test, I can reproduce the crash with earlier versions.
18-03-2020

Caused or triggered by fix for JDK-8211233.
17-03-2020

Seems like this has been introduced in JDK 12 b16 (I can not reproduce with b15).
13-03-2020

ILW = Assert in C2's matcher, reproducible with fuzzer test, no known workaround (but disable compilation of affected method) = HLM = P3
13-03-2020