Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8267689

[8u] [aarch64] Crash due to bad shift in indirect addressing mode



    • b05
    • aarch64


      This issue was initially reported against Corretto 8 (https://github.com/corretto/corretto-8/issues/302), but it affects all version of OpenJDK8u on aarch64.

      @charliegracie has provided the following reproducer for a problem which led to intermittent crashes on linux/aarch64:

      $ wget https://mirror.dsrg.utoronto.ca/apache/tomcat/tomcat-8/v8.5.65/bin/apache-tomcat-8.5.65.zip
      $ unzip -q apache-tomcat-8.5.65.zip
      $ cd apache-tomcat-8.5.65
      $ wget https://repo1.maven.org/maven2/com/datadoghq/dd-java-agent/0.75.0/dd-java-agent-0.75.0.jar
      $ cp ./webapps/docs/appdev/sample/sample.war webapps/
      $ java -Djava.util.logging.config.file=./conf/logging.properties \
        -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
        -Xms1g -Xmx1g -XX:ReservedCodeCacheSize=128m -XX:CICompilerCount=2 \
        -javaagent:dd-java-agent-0.75.0.jar -Ddd.service.name=platform -Ddd.tags=env:prod \
        -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources \
        -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= \
        -classpath ./bin/bootstrap.jar:./bin/tomcat-juli.jar \
        -Dcatalina.base=./ -Dcatalina.home=./ -Djava.io.tmpdir=./temp \
        org.apache.catalina.startup.Bootstrap start

      From another shell do (with the [`armcrash.txt`](https://github.com/corretto/corretto-8/files/6443894/armcrash.txt) jmeter file attached to this issue):

      $ wget https://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist//jmeter/binaries/apache-jmeter-5.4.1.tgz
      $ tar -xzf apache-jmeter-5.4.1.tgz
      $ cd apache-jmeter-5.4.1

      rm -rf /tmp/jmeter.report/* /tmp/jmeter.log && \
        ./bin/jmeter -n -t /priv/ec2-user/tomcat-crash/armcrash.txt -l /tmp/jmeter.log -e -o /tmp/jmeter.report/

      If Tomcat doesn't crash restart it and re-run jmeter. Repeat until you see a crash (might require 10-20 runs).

      If you run this in a debug build, the following asserton will trigger:

      # A fatal error has been detected by the Java Runtime Environment:
      # Internal Error (/priv/ec2-user/OpenJDK/jdk8u-dev/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:480), pid=301100, tid=0x0000fffeb1d4f1e0
      # assert(_ext.shift() == (int)size) failed: bad shift
      # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-ec2user_2021_04_28_18_11-b00)
      # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-aarch64 compressed oops)
      # Core dump written. Default location: /priv/ec2-user/tomcat-crash/reproducer/apache-tomcat-8.5.65/core or core.301100
      # If you would like to submit a bug report, please visit:
      # http://bugreport.java.com/bugreport/crash.jsp

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

      Current thread (0x0000ffff79016800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=301153, stack(0x0000fffeb1b50000,0x0000fffeb1d50000)]

      Stack: [0x0000fffeb1b50000,0x0000fffeb1d50000], sp=0x0000fffeb1d4a690, free space=2025k
      Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.so+0xff0344] VMError::report_and_die()+0x24c
      V [libjvm.so+0x68feb4] report_vm_error(char const*, int, char const*, char const*)+0x6c
      V [libjvm.so+0x280684] Address::encode(Instruction_aarch64*) const+0x3ec
      V [libjvm.so+0x26ae20] Assembler::ld_st2(RegisterImpl*, Address const&, int, int, int) [clone .constprop.168]+0xa8
      V [libjvm.so+0x21bcd4] loadStore(MacroAssembler, void (MacroAssembler::*)(RegisterImpl*, Address const&), RegisterImpl*, int, RegisterImpl*, int, int, int) [clone .constprop.154]+0x19c
      V [libjvm.so+0x22431c] storeNNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x19c
      V [libjvm.so+0x5f85fc] Compile::scratch_emit_size(Node const*)+0x2a4
      V [libjvm.so+0xd5f30c] Compile::shorten_branches(unsigned int*, int&, int&, int&)+0x24c
      V [libjvm.so+0xd60278] Compile::init_buffer(unsigned int*)+0x298
      V [libjvm.so+0xd69f1c] Compile::Output()+0x2bc
      V [libjvm.so+0x60515c] Compile::Code_Gen()+0x3fc
      V [libjvm.so+0x6081e8] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xda0
      V [libjvm.so+0x4c00d8] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xd8
      V [libjvm.so+0x612b64] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x384
      V [libjvm.so+0x614134] CompileBroker::compiler_thread_loop()+0x5c4
      V [libjvm.so+0xf6cec0] JavaThread::thread_main_inner()+0x1f0
      V [libjvm.so+0xf6d0d0] JavaThread::run()+0x1d0
      V [libjvm.so+0xd4295c] java_start(Thread*)+0x16c
      C [libpthread.so.0+0x7718] start_thread+0x1a0
      C [libc.so.6+0xd207c] thread_start+0xc

      Current CompileTask:
      C2: 36621 6751 4 org.jctools.queues.MpscBlockingConsumerArrayQueue::offer (121 bytes)

      Notice that this issue only affects OpenJDK8u. In later releases it was fixed by JDK-8154826 which completely reworked complex addressing modes. Because that change doesn't apply cleanly (i.e. depends on JDK-8136820, JDK-8034812, etc) and also affects other platforms I suggest a point fix here which only fixes the current issue in jdk8u by checking the shift amount against the size of the memory operation in the Matcher and rejecting address modes where they don't conform (see https://github.com/corretto/corretto-8/pull/303).


        Issue Links



              simonis Volker Simonis
              simonis Volker Simonis
              0 Vote for this issue
              3 Start watching this issue