<div dir="ltr">I'll have to check tomorrow, but it's not unreasonable to think that it is. Â It is a stack frame on a thread that was started before the class redefinition happened.<div><br></div><div>I guess the question is: what makes sense to do here? Â I put in a workaround such that, if m is null, method_id is replaced by the method_id from mp. Â I could refactor the code a little, such that the full version of create() took the Method* instead of taking the method_id, and pass it mp if m is null.</div>

<div><br></div><div>It'll be hard to get you a reproducible test case, though. Â This only happens in an integration test in our test cluster. Â Debugging was painful.</div><div><br></div><div>Jeremy</div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Wed, Apr 30, 2014 at 6:34 PM, Coleen Phillimore <span dir="ltr"><<a href="mailto:coleen.phillimore@oracle.com" target="_blank">coleen.phillimore@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    We didn't file any bugs because I don't remember finding anything
    specific, other than "gosh that code is scary" and "I wish we didn't
    have to do this".<br>
    <br>
    If you find a null 'm' below and call m->print() is the method
    "obsolete"?<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Coleen</font></span><div><div class="h5"><br>
    <br>
    <div>On 4/30/14, 8:24 PM, Jeremy Manson
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Did the new bugs get filed for this?
        <div><br>
        </div>
        <div>I'm triggering this check with a redefined class (from the
          bootclasspath, if that matters). Â To investigate it a little,
          I instrumented StackTraceElement::create thus:</div>
        <div><br>
        </div>
        <div>oop java_lang_StackTraceElement::create(methodHandle
          method, int bci, TRAPS) {<br>
        </div>
        <div>
          <div>  Handle mirror (THREAD,
            method->method_holder()->java_mirror());</div>
          <div>  int method_id = method->method_idnum();</div>
          <div><br>
          </div>
          <div>  InstanceKlass* holder = method->method_holder();</div>
          <div>  Method* m = holder->method_with_idnum(method_id);</div>
          <div>  Method* mp = holder->find_method(method->name(),
            method->signature());</div>
          <div>  method->print_name();<br>
          </div>
          <div>  fprintf(stderr, " method = %p id = %d method' = %p \n",
            m, method_id, mp);</div>
          <div>  return create(mirror, method_id,
            method->constants()->version(), bci, THREAD);</div>
          <div>}</div>
        </div>
        <div><br>
        </div>
        <div>m is null, and mp isn't. Â method->print_name works fine.
          Â This makes me feel that the idnum array is out of date
          somehow. Â Before I go down the rabbit hole and try to figure
          out why that is, does someone else know why?</div>
        <div><br>
        </div>
        <div>Thanks!</div>
        <div><br>
        </div>
        <div>Jeremy</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Thu, Oct 3, 2013 at 11:02 AM, Coleen
          Phillimore <span dir="ltr"><<a href="mailto:coleen.phillimore@oracle.com" target="_blank">coleen.phillimore@oracle.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Summary:
            Redefined class in stack trace may not be found by
            method_idnum so handle null.<br>
            <br>
            This is a simple change. Â I had another change to save the
            method name (as u2) in the backtrace, but it's not worth the
            extra footprint in backtraces for this rare case.<br>
            <br>
            The root problem was that we save method_idnum in the
            backtrace (u2) instead of Method* to avoid Method* from
            being redefined and deallocated. Â I made a change to
            InstanceKlass::method_from_idnum() to return null rather
            than the last method in the list, which causes this crash. Â 
            Dan and I went down the long rabbit-hole of why method_idnum
            is changed for obsolete methods and we think there's some
            cleanup and potential bugs in this area. Â But this is not
            that change. Â I'll file another bug to continue this
            investigation for jdk9 (or 8uN).<br>
            <br>
            Staffan created a test - am including core-libs for the
            review request. Â Also tested with all of the vm testbase
            tests, mlvm tests, and java/lang/instrument tests.<br>
            <br>
            open webrev at <a href="http://cr.openjdk.java.net/%7Ecoleenp/8025238/" target="_blank">http://cr.openjdk.java.net/~coleenp/8025238/</a><br>
            bug link <a href="https://bugs.openjdk.java.net/browse/JDK-8025238" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8025238</a><br>
            <br>
            test case for jdk8 repository:<br>
            <br>
            open webrev at <a href="http://cr.openjdk.java.net/%7Ecoleenp/8025238_jdk" target="_blank">http://cr.openjdk.java.net/~coleenp/8025238_jdk</a><br>
            <br>
            Thanks,<br>
            Coleen<br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>