Details

    • Subcomponent:
    • CPU:
      x86_64
    • OS:
      linux

      Description

      The following test failed in the JDK17 CI:

      applications/kitchensink/Kitchensink24HStress.java

      Here's a snippet from the log file:

      Output and diagnostic info for process 26569 was saved into 'pid-26569-output.log'
      [stress.process.out] [13641.275s][warning][gc] GC locker is held; pre-dump GC was skipped
      [stress.process.out] #
      [stress.process.out] # A fatal error has been detected by the Java Runtime Environment:
      [stress.process.out] #
      [stress.process.out] # SIGSEGV (0xb) at pc=0x00007fcac0356c21, pid=20906, tid=28535
      [stress.process.out] #
      [stress.process.out] # JRE version: Java(TM) SE Runtime Environment (17.0+4) (build 17-ea+4-LTS-132)
      [stress.process.out] # Java VM: Java HotSpot(TM) 64-Bit Server VM (17-ea+4-LTS-132, mixed mode, sharing, tiered, z gc, linux-amd64)
      [stress.process.out] # Problematic frame:
      [stress.process.out] # V [libjvm.so+0x9e6c21][thread 20961 also had an error]
      [stress.process.out] GetCurrentLocationClosure::do_thread(Thread*)+0x101
      [stress.process.out] #
      [stress.process.out] # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/983c483a-6907-44e0-ad29-98c7183575e2-S15034/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2a43f490-6816-45d1-befd-33e1d3daaf9d/runs/6eccebdf-4682-4831-843f-ac0b232c9984/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/core.20906)
      [stress.process.out] #
      [stress.process.out] # JFR recording file will be written. Location: /opt/mach5/mesos/work_dir/slaves/983c483a-6907-44e0-ad29-98c7183575e2-S15034/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2a43f490-6816-45d1-befd-33e1d3daaf9d/runs/6eccebdf-4682-4831-843f-ac0b232c9984/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid20906.jfr
      [stress.process.out] #
      [stress.process.out] Unsupported internal testing APIs have been used.
      [stress.process.out]
      [stress.process.out] # An error report file with more information is saved as:
      [stress.process.out] # /opt/mach5/mesos/work_dir/slaves/983c483a-6907-44e0-ad29-98c7183575e2-S15034/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2a43f490-6816-45d1-befd-33e1d3daaf9d/runs/6eccebdf-4682-4831-843f-ac0b232c9984/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid20906.log
      [stress.process.out] [thread 19627 also had an error][thread 19628 also had an error]
      [stress.process.out]
      [2020-12-31T07:05:35.394556968Z] Gathering output for process 28543
      [2020-12-31T07:05:35.402947306Z] Waiting for completion for process 28543
      [2020-12-31T07:05:35.403020354Z] Waiting for completion finished for process 28543
      Output and diagnostic info for process 28543 was saved into 'pid-28543-output.log'

      Here's the crashing thread's stack from the hs_err_pid file:

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

      Current thread (0x00007fc7f84a3f40): JavaThread "MemAccessWorkerThread" [_thread_in_vm, id=28535, stack(0x00007fc79d7f0000,0x00007fc79d8f1000)]

      Stack: [0x00007fc79d7f0000,0x00007fc79d8f1000], sp=0x00007fc79d8eb650, free space=1005k
      Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.so+0x9e6c21] GetCurrentLocationClosure::do_thread(Thread*)+0x101
      V [libjvm.so+0x783e44] HandshakeOperation::do_handshake(JavaThread*)+0x44
      V [libjvm.so+0x783f6c] HandshakeState::process_self_inner()+0xac
      V [libjvm.so+0x784084] HandshakeState::process_by_self()+0x54
      V [libjvm.so+0xc87809] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x39
      V [libjvm.so+0xc802d8] ThreadSafepointState::handle_polling_page_exception()+0x138
      v ~SafepointBlob
      v ~StubRoutines::call_stub
      V [libjvm.so+0x7f6215] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2d5
      V [libjvm.so+0x7f7a9b] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x1cb
      V [libjvm.so+0x8b2ee0] thread_entry(JavaThread*, Thread*)+0x70
      V [libjvm.so+0xd7ea9b] JavaThread::thread_main_inner()+0x11b
      V [libjvm.so+0xd8378d] Thread::call_run()+0xfd
      V [libjvm.so+0xbdb007] thread_native_entry(Thread*)+0xe7

      Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
      v ~SafepointBlob
      v ~StubRoutines::call_stub

      siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000

      Since the call to GetCurrentLocationClosure::do_thread() came
      from HandshakeOperation::do_handshake(), I'm starting this
      bug off in hotspot/runtime for initial triage.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              dcubed Daniel Daugherty
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: