JDK-6216196 : jvm crashes filling in exception trace by accessing zombie method.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_06
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-01-11
  • Updated: 2011-06-02
  • Resolved: 2008-07-15
Related Reports
Duplicate :  
JDK-4894843 - RFE: switch from eager deoptimization to lazy deoptimization
Relates :  
JDK-6317989 - Abort (core dumped) occurs related to deoptimization in 1.4.2_07
Relates :  
JDK-4951689 - JVM crashes during deoptimization phase
Description
In bug 4951689 a member of the JDC has found yet another instance of
failing the gaurantee in codeCache for accessing zombie methods. This
was with -server and 1.4.2_06 so it was not an instance of 4951689 but
another new bug. The JDC member included the stack trace which is
included below:

#4  0x0035dc3a in report_error () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#5  0x0035d69d in report_fatal () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#6  0x0033a821 in CodeCache::find_blob () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#7  0x0055e408 in vframeStreamCommon::fill_from_frame ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#8  0x0055e769 in vframeStreamCommon::next ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#9  0x003e0d54 in java_lang_Throwable::fill_in_stack_trace ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#10 0x003e30e6 in java_lang_Throwable::fill_in_stack_trace ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#11 0x0042cb24 in JVM_FillInStackTrace () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#12 0x00f051cd in Java_java_lang_Throwable_fillInStackTrace ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/libjava.so
#13 0x01018b14 in ?? ()
#14 0xcfcfb9e0 in ?? ()
#15 0x0668f1c8 in ?? ()
#16 0xd16b9798 in ?? ()
#17 0x00f20ec0 in ?? ()
#18 0x0668f21c in ?? ()
#19 0xcbbd8240 in ?? ()
#20 0xcfcfb940 in ?? ()
#21 0x0668f208 in ?? ()
#22 0x003c245d in instanceKlass::find_method ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#23 0x003de604 in JavaCalls::call_helper () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#24 0x004c478d in os::os_exception_wrapper ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#25 0x003de856 in JavaCalls::call () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#26 0x003deb12 in JavaCalls::call_special ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#27 0x0038d7d7 in Exceptions::new_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#28 0x0038d9c0 in Exceptions::new_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#29 0x0038da0d in Exceptions::new_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#30 0x003cfd1f in InterpreterRuntime::create_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#31 0x00f20d37 in ?? ()
#32 0xcfcfb940 in ?? ()
#33 0x0061a88f in InlineImageParser::MAX_INPUT_LINE ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#34 0x00000000 in ?? ()
#35 0x00f20d02 in ?? ()
#36 0x00000003 in ?? ()
#37 0xd67be560 in ?? ()
#38 0x0668f4b0 in ?? ()
#39 0xf111367f in ?? ()
...

It is not obvious what is the cause of the failure. Since it is generic
code it is likley that -client also will fail. However the client compilers
use of deoptimization is different enough it might not happen. It seems
likely that using -XX:-StackTraceInThrowable will workaround the problem.
###@###.### 2005-1-11 17:56:25 GMT
Comments
EVALUATION Closed. Fixed in Tiger. Initial fix with lazy deopt rewrite 4894843. Backport would require backporting multiple additional refinements, i.e. bugtrails for 4894843.
15-07-2008
EVALUATION The circa tiger hs_err_pid*.log file in error handling will show out the zombie method in the stack trace. I'm closing this as not reproduceable. If we get more information it can be reopened.
26-08-2005
EVALUATION The failure shows the VM crashing when accessing a zombie method during exception handling but the real problem is that there's a zombie in the stack frame. The zombie method shouldn't be there. Can this be reproduced with java_g or the 5.0 version of the VM so we can see what the zombie method is? Also you can use -XX:+PrintCompilation and selectively disable compilation based on a guess of which compiled function called the zombie function. We should change the stack trace to not abort with a zombie method which would make this diagnosis easier. Is this reproduceable enough that if I did that, you could use my VM to find the offending method? Please let me know. ###@###.### <I really liked the date stamp this used to do>
03-08-2005
WORK AROUND I expect that using -XX:+StackTraceInThrowable will workaround this particular bug. ###@###.### 2005-1-11 17:56:25 GMT Correction, use -XX:-StackTraceInThrowable to workaround this particular bug. ###@###.### 2005-8-3 <why isn't this automatic anymore?>
11-01-2005