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

SEGV in forte backtrace walker under collect command

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b95
    • CPU:
      sparc
    • OS:
      solaris_9

      Description

      I got a crash running JBB under the collector.
      On inspection of the crash log, I found that the code in forte.cpp which validates the Lmethod of an interpreter frame is not cautious enough.

      static inline bool forte_is_valid_method(methodOop method) {
        if (method == NULL ||
            // The methodOop is extracted via an offset from the current
            // interpreter frame. With AsyncGetCallTrace() the interpreter
            // frame may still be under construction so we need to make
            // sure that we got an aligned oop before we try to use it.
            !Space::is_aligned(method) ||
            !Universe::heap()->is_in_reserved((void*)method) ||
            // See if GC became active after we entered AsyncGetCallTrace()
            // and before we try to use the methodOop. This routine is
            // used in validation of the top_frame so we don't have any
            // other data to flush if we bail due to GC here.
            // Yes, there is still a window after this check and before
            // we use methodOop below, but we can't lock out GC so that
            // has to be an acceptable risk.
            Universe::heap()->is_gc_active() ||
            // klass() does not need vtable dispatch so check before is_perm()
            oop(method)->klass() != Universe::methodKlassObj() ||
            !method->is_perm() ||
            !method->is_method()) {
          return false; // doesn't look good
        }
        return true; // hopefully this is a method indeed
      }

      In the above method, the is_perm call must come before the klass check.

      If not, you can get a method pointing into the unmapped part of the heap's reserved area (e.g., a very high address just within bounds), and the instruction which loads the class will SEGV. This is what happened to me.

      (You should remove the comment about a vtable, which appears to be a thoughtless and useless optimization. Nobody cares which order the tests come in, since in most cases both tests are going to be run, since most frame collection attempts are successful.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dcubed Daniel Daugherty
              Reporter:
              jrose John Rose
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: