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

JVMTI process frames on thread without started processing

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P4
    • 16
    • None
    • hotspot
    • None
    • b20

    Description

      This cause asserts like this:

      # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, tid=828734
      # assert(processing_started()) failed: Processing should already have started

      Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5
      V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a
      V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18
      V [libjvm.so+0x1804c4a] vframe::sender() const+0xea
      V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b
      V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c
      V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2
      V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c
      V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215

      The proposal is to dodge this problem by turning of "frame processing" for these calls. The processing is only needed when oops are read, and the current code doesn't read oops.

      Attachments

        Issue Links

          Activity

            People

              stefank Stefan Karlsson
              stefank Stefan Karlsson
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: