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
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
- duplicates
-
JDK-4894843 RFE: switch from eager deoptimization to lazy deoptimization
- Closed
- relates to
-
JDK-4951689 JVM crashes during deoptimization phase
- Closed
-
JDK-6317989 Abort (core dumped) occurs related to deoptimization in 1.4.2_07
- Closed