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 :  
Relates :  
Relates :  
Relates :  
Relates :  
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

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.

EVALUATION http://hg.openjdk.java.net/hsx/hsx17/master/rev/d3562366cbfd

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d3562366cbfd

EVALUATION http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/d3562366cbfd

EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/d3562366cbfd

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d3562366cbfd

SUGGESTED FIX See attached 6949515-webrev-cr0.tgz file for the proposed fix.

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.

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.

WORK AROUND 6u17 can be used as workaround.

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.

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; };