JDK-6949515 : VM crash when calling GetMethodDeclaringClass
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6u18,6u20
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris_nevada,windows_vista
  • CPU: x86
  • Submitted: 2010-05-04
  • Updated: 2016-09-19
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21Fixed 7Fixed OpenJDK6,hs17Fixed
Related Reports
Duplicate :  
JDK-6951571 - JVM crashes when using NetBeans memory profiler
Relates :  
JDK-6952694 - resolve_external_guard() should probably check for deleted_handle()
Relates :  
JDK-8160226 - VM crushed during redeployment of ear module to wildfly 9.0.2.final
Relates :  
JDK-6862945 - conversion of jmethodID to methodOop in JVMTI is too expensive
Relates :  
JDK-8166448 - Crash in Method::checked_resolve_jmethod_id(_jmethodID*)
Description
Invoking GetMethodDeclaringClass with obsolete methodid will crash VM. The bug is originaly reported against NetBeans.
See <https://netbeans.org/bugzilla/show_bug.cgi?id=183107> for steps how to reproduce it.
Here are some snippets from the hs_err file from the NetBeans bug link:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d9bd48f, pid=3564, tid=1044
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Client VM (16.0-b13 mixed mode windows-x86 )
# Problematic frame:
# V  [jvm.dll+0x10d48f]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x04ada000):  JavaThread "*** Profiler Agent Communication Thread" daemon [_thread_in_vm, id=1044, stack(0x04f20000,0x04f70000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000004

Registers:
EAX=0x024894f0, EBX=0x00000d90, ECX=0x000071ee, EDX=0x00000000
ESP=0x04f6fab0, EBP=0x04f6fab4, ESI=0x00000000, EDI=0x02411490
EIP=0x6d9bd48f, EFLAGS=0x00010206

Top of Stack: (sp=0x04f6fab0)
0x04f6fab0:   04ada000 04f6fadc 6d9e230f 024894f0
0x04f6fac0:   058126e4 024894f0 04ada000 00000000
0x04f6fad0:   00000000 00000000 04ada000 75eb3e00
0x04f6fae0:   10002594 02411490 024894f0 04f6fb28
0x04f6faf0:   04ada000 20152eb0 04f6fb60 20152eb0
0x04f6fb00:   04c238f8 04c9f5a8 058126e4 00000a65
0x04f6fb10:   00000000 00000000 05811a38 02509f47
0x04f6fb20:   04ada110 04f6fb68 04e818f0 04ce1878 

Instructions: (pc=0x6d9bd48f)
0x6d9bd47f:   cc 55 8b ec 8b 45 08 85 c0 75 02 5d c3 56 8b 30
0x6d9bd48f:   8b 46 04 8d 48 08 8b 01 ff 90 94 00 00 00 f6 d8 


Stack: [0x04f20000,0x04f70000],  sp=0x04f6fab0,  free space=13e04f6f594k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x10d48f]
V  [jvm.dll+0x13230f]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
j  org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+18
j  org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+532
j  org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
j  org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
v  ~StubRoutines::call_stub


Just to be clear: with product bits, this bug crashes with an
EXCEPTION_ACCESS_VIOLATION. With debug bits, this bug crashes
with a nice assertion failure.

I've attached the complete hs_err file from the NetBeans link
as hs_err_pid3564.log.
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/master/rev/d3562366cbfd
21-05-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d3562366cbfd
19-05-2010
EVALUATION http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/d3562366cbfd
18-05-2010
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/d3562366cbfd
18-05-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d3562366cbfd
17-05-2010
SUGGESTED FIX See attached 6949515-webrev-cr0.tgz file for the proposed fix.
14-05-2010
EVALUATION I think that JNIHandles::checked_resolve_jmethod_id() needs to use JNIHandles::resolve_external_guard() instead of using JNIHandles::resolve_non_null(). Prior to the fix for 6862945, the call to resolve_non_null() was protected by the weak reference check: if (is_weak_global_handle(handle)) { return (methodOop) resolve_non_null(handle); } else { I'll need to mull on this a bit more.
06-05-2010
SUGGESTED FIX You don't want to make the changes to JNIHandles::resolve_jmethod_id() that are proposed in the previous note. resolve_jmethod_id() is for use in situations where your jmethodID is supposed to be good, i.e., the only "extra" checks on that code path are assertions. JNIHandles::checked_resolve_jmethod_id() definitely needs to be changed, but again, not in the way described in the previous note.
06-05-2010
WORK AROUND 6u17 can be used as workaround.
04-05-2010
PUBLIC COMMENTS Invoking GetMethodDeclaringClass with obsolete methodid will crash VM. The bug is originaly reported against NetBeans. See <https://netbeans.org/bugzilla/show_bug.cgi?id=183107> for steps how to reproduce it.
04-05-2010
SUGGESTED FIX One of the ways how to fix it is to change JNIHandles::resolve_jmethod_id() and allow to return NULL (since this is legitime case) and change JNIHandles::checked_resolve_jmethod_id() to return NULL if JNIHandles::resolve_jmethod_id() returns NULL. See the patch against OpenJDK 6 repository below: diff -r 587f774a3e70 src/share/vm/runtime/jniHandles.hpp --- a/src/share/vm/runtime/jniHandles.hpp Wed Apr 14 14:33:46 2010 -0700 +++ b/src/share/vm/runtime/jniHandles.hpp Tue May 04 15:51:43 2010 +0200 @@ -196,7 +196,12 @@ }; inline methodOop JNIHandles::resolve_jmethod_id(jmethodID mid) { - return (methodOop) resolve_non_null((jobject)mid); + assert(mid != NULL, "jmethodID handle should not be null"); + oop result = *(oop*)mid; + assert(result != badJNIHandle, "Pointing to zapped jmethodID handle area"); + // Don't let that private _deleted_handle object escape into the wild. + assert(result != deleted_handle(), "Used a deleted jmethodID."); + return (methodOop)result; }; inline methodOop JNIHandles::checked_resolve_jmethod_id(jmethodID mid) { @@ -204,12 +209,12 @@ return (methodOop) NULL; } - oop o = resolve_non_null((jobject) mid); - if (!o->is_method()) { + methodOop o = resolve_jmethod_id(mid); + if (o == NULL || !((oop)o)->is_method()) { return (methodOop) NULL; } - return (methodOop) o; + return o; };
04-05-2010