United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6949515 VM crash when calling GetMethodDeclaringClass
JDK-6949515 : VM crash when calling GetMethodDeclaringClass

Details
Type:
Bug
Submit Date:
2010-05-04
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
windows_vista,linux,solaris_nevada
Sub-Component:
jvmti
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u18,6u20
Fixed Versions:
hs19 (b02)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:

Sub Tasks

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
WORK AROUND

6u17 can be used as workaround.
                                     
2010-05-04
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;
 };
                                     
2010-05-04
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.
                                     
2010-05-04
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.
                                     
2010-05-06
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.
                                     
2010-05-06
SUGGESTED FIX

See attached 6949515-webrev-cr0.tgz file for the proposed fix.
                                     
2010-05-14
EVALUATION

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

http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/d3562366cbfd
                                     
2010-05-18
EVALUATION

http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/d3562366cbfd
                                     
2010-05-18
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d3562366cbfd
                                     
2010-05-19
EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/master/rev/d3562366cbfd
                                     
2010-05-21



Hardware and Software, Engineered to Work Together