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

JFR Recorder Thread crashed with SIGSEGV in write_klass

    XMLWordPrintable

    Details

    • Subcomponent:
      jfr
    • Resolved In Build:
      b35

      Backports

        Description

        The following test crashed in the JDK17 CI:

        applications/runthese/RunThese30M.java

        Here's snippets from the hs_err_pid file:

        # SIGSEGV (0xb) at pc=0x00007f1f1ac113d4, pid=2253, tid=2314
        #
        # JRE version: Java(TM) SE Runtime Environment (17.0+34) (build 17-ea+34-LTS-2715)
        # Java VM: Java HotSpot(TM) 64-Bit Server VM (17-ea+34-LTS-2715, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
        # Problematic frame:
        # V [libjvm.so+0x8703d4] write_klass(JfrCheckpointWriter*, Klass const*, bool)+0x234

        <snip>

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

        Current thread (0x00007f1c68e47510): JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=2314, stack(0x00007f1ce53eb000,0x00007f1ce54ec000)]

        Stack: [0x00007f1ce53eb000,0x00007f1ce54ec000], sp=0x00007f1ce54ea830, free space=1022k
        Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
        V [libjvm.so+0x8703d4] write_klass(JfrCheckpointWriter*, Klass const*, bool)+0x234
        V [libjvm.so+0x876750] JfrArtifactCallbackHost<Klass const*, CompositeFunctor<Klass const*, CompositeFunctor<Klass const*, JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Klass const*, LeakPredicate<Klass const*>, &(write__klass__leakp(JfrCheckpointWriter*, void const*))>, 164u>, JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Klass const*, SerializePredicate<Klass const*>, &(write__klass(JfrCheckpointWriter*, void const*))>, 164u> >, KlassArtifactRegistrator> >::do_artifact(void const*)+0xb0
        V [libjvm.so+0x868d9d] EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >::dispatch(bool, unsigned char const*, unsigned long)+0xad
        V [libjvm.so+0x868e77] void JfrLinkedList<JfrBuffer, JfrCHeapObj>::iterate<CompositeOperation<EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >, ReinitializeAllReleaseRetiredOp<JfrMemorySpace<JfrEpochStorageHost<JfrBuffer, JfrMspaceRemoveRetrieval, false>, JfrMspaceRemoveRetrieval, JfrConcurrentQueue<JfrBuffer, JfrCHeapObj>, JfrLinkedList<JfrBuffer, JfrCHeapObj>, true>, JfrLinkedList<JfrBuffer, JfrCHeapObj> >, CompositeOperationAnd> >(CompositeOperation<EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >, ReinitializeAllReleaseRetiredOp<JfrMemorySpace<JfrEpochStorageHost<JfrBuffer, JfrMspaceRemoveRetrieval, false>, JfrMspaceRemoveRetrieval, JfrConcurrentQueue<JfrBuffer, JfrCHeapObj>, JfrLinkedList<JfrBuffer, JfrCHeapObj>, true>, JfrLinkedList<JfrBuffer, JfrCHeapObj> >, CompositeOperationAnd>&)+0x57
        V [libjvm.so+0x8690b1] void JfrEpochStorageHost<JfrBuffer, JfrMspaceRemoveRetrieval, false>::iterate<EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> > >(EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >&, bool)+0xe1
        V [libjvm.so+0x86897e] JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x3e
        V [libjvm.so+0x871878] do_klasses()+0x38
        V [libjvm.so+0x873634] JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0x284
        V [libjvm.so+0x80d4fb] JfrCheckpointManager::write_type_set()+0xfb
        V [libjvm.so+0x84f6b6] JfrRecorderService::rotate(int)+0xa6
        V [libjvm.so+0x84ff0b] recorderthread_entry(JavaThread*, JavaThread*)+0x1eb
        V [libjvm.so+0xd8e620] JavaThread::thread_main_inner()+0xd0
        V [libjvm.so+0xd91cae] Thread::call_run()+0xde
        V [libjvm.so+0xbe7f51] thread_native_entry(Thread*)+0xe1


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

        I have not seen this failure mode before so I'm tagging this
        bug as a regression and starting it at P2. The triage team can
        adjust as needed.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                mgronlun Markus Grönlund
                Reporter:
                dcubed Daniel Daugherty
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: