JDK-6209701 : jvm crashes failing "unsafe access to zombie method" gaurantee
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_06
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-12-16
  • Updated: 2012-10-08
  • Resolved: 2006-06-26
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.
Other
1.4.2_13 b01Fixed
Related Reports
Relates :  
JDK-4951689 - JVM crashes during deoptimization phase
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
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
11-08-2005
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.
11-08-2005
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
16-12-2004