JDK-8284883 : JVM crash: guarantee(sect->end() <= sect->limit()) failed: sanity on AVX512
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17.0.2,19
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2022-03-30
  • Updated: 2022-07-12
  • Resolved: 2022-04-29
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 17 JDK 19
17.0.5-oracleFixed 19 b21Fixed
Related Reports
Relates :  
JDK-8166561 - [s390] Adaptions needed for s390 port in C1 and C2.
Description
A DESCRIPTION OF THE PROBLEM :
JVM crashed when I run SPECjvm. No errors are reported when running in JDK11, but when running in JDK17, JVM crashed.

Reproduce: java -jar -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-IdealizeClearArrayNode SPECjvm2008.jar startup.sunflow -ikv

hs_err log:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (codeBuffer.cpp:973), pid=21701, tid=21743
#  guarantee(sect->end() <= sect->limit()) failed: sanity
#
# JRE version: Java(TM) SE Runtime Environment (17.0.2+8) (build 17.0.2+8-LTS-86)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.2+8-LTS-86, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x574704]  CodeBuffer::verify_section_allocation()+0x204
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/jiahx/SPECjvm2008/core.21701)
#
# 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: -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-IdealizeClearArrayNode SPECjvm2008.jar startup.sunflow -ikv

Host: Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz, 16 cores, 31G, Ubuntu 18.04.6 LTS
Time: Wed Mar 30 16:43:38 2022 CST elapsed time: 4.418891 seconds (0d 0h 0m 4s)

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

Current thread (0x00007fc744178730):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=21743, stack(0x00007fc703069000,0x00007fc70316a000)]


Current CompileTask:
C2:   4418 3498    b  4       java.util.Properties$LineReader::<init> (38 bytes)

Stack: [0x00007fc703069000,0x00007fc70316a000],  sp=0x00007fc703165520,  free space=1009k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x574704]  CodeBuffer::verify_section_allocation()+0x204
V  [libjvm.so+0x574a0f]  CodeBuffer::~CodeBuffer()+0xf
V  [libjvm.so+0xbff167]  PhaseOutput::scratch_emit_size(Node const*)+0x297
V  [libjvm.so+0xbfaf50]  PhaseOutput::shorten_branches(unsigned int*)+0x280
V  [libjvm.so+0xc032aa]  PhaseOutput::Output()+0x58a
V  [libjvm.so+0x59eea4]  Compile::Code_Gen()+0x5f4
V  [libjvm.so+0x5a484b]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x148b
V  [libjvm.so+0x4e8579]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xe9
V  [libjvm.so+0x5ad061]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd81
V  [libjvm.so+0x5adbf8]  CompileBroker::compiler_thread_loop()+0x4b8
V  [libjvm.so+0xd917e0]  JavaThread::thread_main_inner()+0xd0
V  [libjvm.so+0xd94e6e]  Thread::call_run()+0xde
V  [libjvm.so+0xbeae11]  thread_native_entry(Thread*)+0xe1

REGRESSION : Last worked in version 11.0.14-oracle


FREQUENCY : always
Comments
Fix request [17u] I backport this for parity with 17.0.5-oracle. A C2 fix we should have. I had to resolve due to context differences. Test passes, but I cannot reproduce the error without the fix. SAP nighlty testing passed.
20-06-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/469 Date: 2022-06-15 09:54:08 +0000
15-06-2022
Thanks Dean. JDK-8287772 has been filed to track this new issue.
03-06-2022
[~chegar], it looks like a different bug to me.
02-06-2022
The hs_err log file over on this Elasticsearch issue [1] would appear to result from the same root cause as the one described by this bug report. And also the version numbers would indicate that it is possible, since this issue has not be been back ported to an 18 update either. I would initially like to confirm that the ES issue [1] is as a result of this JDK bug. And not something else lurking in this area. # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (codeBuffer.cpp:962), pid=19, tid=20 # guarantee(sect->end() <= tend) failed: sanity # # JRE version: (18.0.1.1+2) (build ) # Java VM: OpenJDK 64-Bit Server VM (18.0.1.1+2-6, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x582c9c] CodeBuffer::verify_section_allocation()+0x36c # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /usr/share/elasticsearch/core.19) # # [1] https://github.com/elastic/elasticsearch/issues/87173#issuecomment-1143683923
02-06-2022
Changeset: cd8709e8 Author: Dean Long <dlong@openjdk.org> Date: 2022-04-29 19:09:58 +0000 URL: https://git.openjdk.java.net/jdk/commit/cd8709e8e05897d131afba221970c0866b3d126d
29-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8457 Date: 2022-04-28 19:42:05 +0000
28-04-2022
There seem to be two different problems contributing to this crash. The first is that InitArrayShortSize can be set to arbitrarily large values, and the second is that we don't always check the value of InitArrayShortSize when IdealizeClearArrayNode is turned off.
26-04-2022
ILW = crash with -XX:-IdealizeClearArrayNode; AVX512 only; workaround: -XX:UseAVX=2 = MMM = P3
25-04-2022
This reproduces on startup on a machine with AVX512 using -XX:UseAVX=3. Workaround: -XX:UseAVX=2
25-04-2022
[~sswsharm]: could you please check with the submitter if there is any additional configuration or tweak that must be done to SPECjvm2008 to reproduce the failure on JDK 17? Thanks!
25-04-2022
I cannot reproduce the failure, neither following the additional information from the submitter (I get the same early failure as [~sswsharm] above), nor using the attached replay file.
25-04-2022
Additional Information from submitter: ============================== Here is the exact process I used to reproduce it. First, download the SPECjvm jar package from the SPECjvm website (https://www.spec.org/jvm2008/) and run the command "java -jar SPECjvm2008_1_01_setup.jar -i console " to install it. After SPECjvm installation is complete, move to the SPECjvm2008.jar directory and in its directory, run " java -jar -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:-IdealizeClearArrayNode SPECjvm2008.jar startup.sunflow -ikv". Attached snapshot, hs_err_pid.log, replay_pid.log.
22-04-2022
additional-information-requested ================================================ getting benchmark failed message when trying to run SPECjvm " [iter=1] Iteration failed. [iter=1][bt:1|op:1] java.lang.IllegalAccessError: class spec.benchmarks.check.Main (in unnamed module @0x4047e255) cannot access class com.sun.tools.javac.main.JavaCompiler (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.main to unnamed module @0x4047e255" Could you please confirm if the steps to reproduce this issue are proper? =================================================
14-04-2022