On 10/3/2013 7:01 PM, Daniel D. Daugherty wrote:
On 10/3/13 4:56 PM, Coleen Phillmore wrote:
Thanks Dan -
On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote:
> http://cr.openjdk.java.net/~coleenp/8025238/
src/share/vm/classfile/javaClasses.cpp
1804 if (method == NULL) {
1805 // leave name and fileName null
1806 java_lang_StackTraceElement::set_lineNumber(element(), -1);
Is it possible to set the name and fileName to something?
A caller may not be expecting those to be NULL.
Also, holder->method_with_idnum(method_id) should be able to
search the previous class version list and find the obsolete
Method* that matches the 'method_id' value.
We don't save the obsolete versions on the previous version list,
only the emcp versions. I just looked at the old code and that's
always been the case. So the method that has the method_idnum that
isn't supposed to be found is an obsolete method.
Clearly I've forgotten... thumbs up!
:)
Thanks,
Coleen
Dan
Coleen
src/share/vm/prims/jvmtiRedefineClasses.cpp
Better comment than the original.
Dan
On 10/3/13 12:02 PM, Coleen Phillimore wrote:
Summary: Redefined class in stack trace may not be found by
method_idnum so handle null.
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.
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).
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.
open webrev at http://cr.openjdk.java.net/~coleenp/8025238/
bug link https://bugs.openjdk.java.net/browse/JDK-8025238
test case for jdk8 repository:
open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk
Thanks,
Coleen
