United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6209701 : jvm crashes failing "unsafe access to zombie method" gaurantee

Details
Type:
Bug
Submit Date:
2004-12-16
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2006-06-26
Component:
hotspot
OS:
windows_2000
Sub-Component:
runtime
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_06
Fixed Versions:
1.4.2_13 (b01)

Related Reports
Relates:

Sub Tasks

Description
The customer supplied a stack trace (see bug 4951689) that shows
that this occurs in  Runtime1::resolve_invoke at the following code:

  // It's possible that deoptimization can occur at a call site which hasn't
  // been resolved yet, in which case this function will appear to be called
  // from the deoptimization stub.  If that happens then the top vframeArray
  // will have the original call pc so that method resolution can proceed.
  CodeBlob* cb = CodeCache::find_blob(caller_pc);
  if (cb->is_deoptimization_stub()) {
    vframeArray* array = thread->vframe_array_head();
    caller_pc = array->original_pc();
    cb = CodeCache::find_blob(caller_pc);
  }

the final find_blob is the culprit.

###@###.### 2004-12-16 20:18:24 GMT

                                    

Comments
WORK AROUND

This bug is related to bug 4951689 which was reported
against -server and was fixed in 1.4.2_06. This bug is
in client only code. So if you have 1.4.2_06 or later then
using -server will work around it (assuming there aren't
more bugs like this waiting...).

###@###.### 2004-12-16 20:35:50 GMT
                                     
2004-12-16
SUGGESTED FIX

src/share/vm/c1/c1_Runtime1.cpp:
   287    // It's possible that deoptimization can occur at a call site which hasn't
   288    // been resolved yet, in which case this function will appear to be called
   289    // from the deoptimization stub.  If that happens then the top vframeArray
   290    // will have the original call pc so that method resolution can proceed.
   291    CodeBlob* cb = CodeCache::find_blob(caller_pc);
   292    if (cb->is_deoptimization_stub()) {
   293      vframeArray* array = thread->vframe_array_head();
   294      caller_pc = array->original_pc();
   295      cb = CodeCache::find_blob(caller_pc);
            cb = CodeCache::find_blob_unsafe(caller_pc);
   296    }


See http://jpsesvr.sfbay.sun.com:8080/ctetools/CodeStore/1630/webrev/webrev.html
                                     
2005-08-11
EVALUATION

As Steve says:
We can have no activations on the stack
while we are awaiting deopt and so a 
non-entrant can go zombie. If that happens
then this find_blob lookup will fail.
                                     
2005-08-11



Hardware and Software, Engineered to Work Together