Bug ID: JDK-5007709 VM crashes on deoptimization

JDK-5007709 : VM crashes on deoptimization

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 1.4.2_04

Priority: P1
Status: Resolved
Resolution: Fixed
OS: solaris_9
CPU: sparc

Submitted: 2004-03-04
Updated: 2004-04-07
Resolved: 2004-04-07

Versions (Unresolved/Resolved/Fixed)

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_05 05Fixed

Related Reports

Relates :

JDK-4692404 - com.sun.jdi.ClassType.invokeMethod causes a crash of debugee

Description

VM crashes at decompilation of a given method.
Crash does not happen with -Xint.
Crash does not happen with 1.4.2_02
Crash happens with 1.4.2_04_b4 on 64 Bit 

Unexpected Signal : 10 occurred at PC=0xFFFFFFFF3841A728
Function=[Unknown.]
Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Current Java thread:

Dynamic libraries:
0x100000000 /usr/sap/E00/JC00/j2ee/os_libs/jlaunch
0xffffffff7f400000 /usr/lib/sparcv9/libdl.so.1
0xffffffff7f100000 /usr/lib/sparcv9/libnsl.so.1
0xffffffff7ef00000 /usr/lib/sparcv9/libsocket.so.1
0xffffffff7ed00000 /usr/sap/E00/JC00/j2ee/os_libs/libsapu16_mt.so
0xffffffff7ea00000 /usr/lib/sparcv9/libm.so.1
0xffffffff7e800000 /usr/lib/sparcv9/libCrun.so.1
0xffffffff7f300000 /usr/lib/sparcv9/libw.so.1
0xffffffff7e500000 /usr/lib/sparcv9/libthread.so.1
0xffffffff7e300000 /usr/lib/sparcv9/libc.so.1
0xffffffff7e000000 /usr/lib/64/libmp.so.2
0xffffffff7e700000 /usr/platform/SUNW,
Sun-Fire-V240/lib/sparcv9/libc_psr.so.1
0xffffffff7db00000 /usr/sap/E00/JC00/j2ee/os_libs/libicuuc.so.20
0xffffffff7d000000 /usr/sap/E00/JC00/j2ee/os_libs/libicudt20b.so
0xffffffff7ce00000 /usr/lib/sparcv9/libpthread.so.1
0xffffffff7bc00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/server/libjvm.so
0xffffffff7ba00000 /usr/lib/64/libsched.so.1
0xffffffff7b100000 /usr/j2sdk1.4.
2_04/jre/lib/sparcv9/native_threads/libhpi.so
0xffffffff7af00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libverify.so
0xffffffff7ad00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libjava.so
0xffffffff7aa00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libzip.so
0xfffffffeee500000 /usr/lib/locale/en_US.ISO8859-1/sparcv9/en_US.
ISO8859-1.so.2
0xfffffffeee300000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libjdwp.so
0xfffffffeee000000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libdt_socket.so
0xfffffffeede00000 /usr/lib/64/nss_files.so.1
0xfffffffee9f00000 /usr/sap/E00/JC00/j2ee/os_libs/libjperflib.so
0xfffffffee9c00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libnet.so
0xfffffffed4b00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libioser12.so
0xfffffffecf500000 /usr/lib/64/nss_nis.so.1

Heap at VM Abort:
Heap
def new generation total 127232K, used 64767K [0xfffffffeeec00000,
0xfffffffef6c00000, 0xfffffffefec00000)
eden space 123392K, 50% used [0xfffffffeeec00000, 0xfffffffef2914580,
0xfffffffef6480000)
from space 3840K, 57% used [0xfffffffef6480000, 0xfffffffef66ab788,
0xfffffffef6840000)
to space 3840K, 0% used [0xfffffffef6840000, 0xfffffffef6840000,
0xfffffffef6c00000)
tenured generation total 393216K, used 320775K [0xfffffffefec00000,
0xffffffff16c00000, 0xffffffff2ec00000)
the space 393216K, 81% used [0xfffffffefec00000, 0xffffffff12541f48,
0xffffffff12542000, 0xffffffff16c00000)
compacting perm gen total 131072K, used 103876K [0xffffffff2ec00000,
0xffffffff36c00000, 0xffffffff36c00000)
the space 131072K, 79% used [0xffffffff2ec00000, 0xffffffff35171268,
0xffffffff35171400, 0xffffffff36c00000)

Local Time = Mon Mar 1 15:12:35 2004
Elapsed Time = 1095
#
# HotSpot Virtual Machine Error : 10
# Error ID : 4F530E43505002EF 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20040219141514.kvn.1.4.
2_04_sap mixed mode)
#
# An error report file has been saved as hs_err_pid12523.log.
# Please refer to the file for further information.

ified that the crash happens during deoptimization
of this method. Perfect. Could you, please, gzip the log and
ask Stefan to put it where I can download it.

And if you saw such crash in 1.4.2_01 it may not introduced
by our fixes. 

Today I continued to analyze the core file with big help 
from Tom R. and John R. 

We got disassembled compiled code and bytecode for this method 
from the core file using SA. And, it seems, we have a problem with 
restoring expression stack during deoptimization or restarting 
process in interpreter (bytecode from wich to continue may be wrong)
when we hit uncommon trap. It could be again the edge case which we
never had before.

Dirk, could you, please, rerun fastdebug JVM but WITHOUT those flags
(it should be faster)? And use the file .hotspot_compiler with 
this print instruction:

print com/sapportals/portal/prt/util/StringUtils escapeToJS

It will print a pseudo-assembler code generated for this method.
Then gzip and send it to me. It should have more info then in 
the core file.

Thanks,
Vladimir

"Marwinski, Dirk" wrote:
> 
> Hi Vladimir,
> 
> > Ok. So we have the workaround now.
> 
> Our results strongly indicate this.
> 
> > My main concern here is this problem was introduced by our
> > fixes or it was there before. What is puzzling me is this
> > Stefan's comment:
> > "This crash did never happen with the original VM 1.4.2_02."
> 
> > Does it mean you were able to pass the original (4985384) crash
> > and this crash with 1.4.2_02?
> 
> This was in fact my statement which I took from the admin of
> the system here. I will try to verify this myself. From what I
> have seen, it looks that the problem did exist in 1.4.2_01, did
> not exist in 1.4.2_02 + 03 and was re-introduced in 1.4.2_04. We
> did have similar crashes on other systems which we could not
> reproduce with 1.4.02_02 that did exist in 01. This is however
> only a suspicion!
> 
> > Unfortunately you may not get crash with fastdebug build.
> > You can stop testing if you can grep the log file
> > for "{method} 'escapeToJS'". Which would mean we passed the deoptimization
> > for this method. Stop testing also if the log file is very big:
> > it will be difficult to analyze it anyway.
> 
> It did crash. The log is approx 700MB. The following is at the end:
> 
> ------------------------
> DEOPT PACKING thread 0x101771678 Compiled frame (sp=0xfffffffee0ffb450, fp=0xfff
> ffffee0ffb520, pc=0xffffffff382bb570)
>      nmethod:{method} 'escapeToJS' '(Ljava/lang/String;)Ljava/lang/String;' in '
> com/sapportals/portal/prt/util/StringUtils'
>      Virtual frames (innermost first):
>         0 - com.sapportals.portal.prt.util.StringUtils.escapeToJS(StringUtils.ja
> va:90) - invokevirtual @ bci 232
>      Created vframeArray 0x103183ef8
> DEOPT UNPACKING thread 0x101771678 vframeArray 0x103183ef8
>      {method} 'escapeToJS' '(Ljava/lang/String;)Ljava/lang/String;' in 'com/sapp
> ortals/portal/prt/util/StringUtils' - invokevirtual @ bci 232 sp = 0xfffffffee0f
> fb470
> 
> Unexpected Signal : 10 occurred at PC=0xFFFFFFFF3703604C
> Function=[Unknown.]
> Library=(N/A)
> 
> NOTE: We are unable to locate the function name symbol for the error
>       just occurred. Please refer to release documentation for possible
>       reason and solutions.
> [...]
> --------------------------------------------------
> 
> Thanks,
> Dirk

Comments

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta2 FIXED IN: 1.4.2_05 tiger-beta2 INTEGRATED IN: 1.4.2_05 tiger-beta2
14-06-2004
SUGGESTED FIX ###@###.### 2004-03-04 From the 4692404 fix. ###@###.### 2004-03-06 Additional problems were found during full PRT 1.4.2_04_sap testing. To fix them I have to modify this fix (in parse1.cpp). It seems, the first implementation of the fix was depend on other changes in 1.5.0 and it was not valid for 1.4.2. Diffs: src/share/vm/opto/callGenerator.cpp Thu Mar 4 17:12:47 2004 ************* * 136,141 ** --- 136,142 ---- // the call instruction will have a seemingly deficient out-count. // (The bailout says something misleading about an "infinite loop".) if (kit.gvn().type(receiver)->higher_equal(TypePtr::NULL_PTR)) { + kit.inc_sp(method()->arg_size()); // restore arguments kit.do_athrow(Deoptimization::Deopt_null_check); return kit.transfer_exceptions_into_jvms(); } src/share/vm/opto/parse1.cpp Thu Mar 4 17:14:39 2004 *********** * 449,455 **** SafePointNode* entry_map = create_entry_map(); // Check for bailouts during map initialization ! if (parse_failed()) { show_bailout_info(); if (log) log->done("parse"); return; --- 449,455 ---- SafePointNode* entry_map = create_entry_map(); // Check for bailouts during map initialization ! if (parse_failed() \|\| entry_map == NULL) { show_bailout_info(); if (log) log->done("parse"); return; ************* * 957,965 **** // If this is an inlined method, we may have to do a receiver null check. if (_caller->has_method() && is_normal_parse() && !method()->is_static()) { GraphKit kit(_caller); ! Node* receiver = kit.argument(0); ! kit.do_null_check(receiver, T_OBJECT); _caller = kit.transfer_exceptions_into_jvms(); } assert(method() != NULL, "parser must have a method"); --- 957,968 ---- // If this is an inlined method, we may have to do a receiver null check. if (_caller->has_method() && is_normal_parse() && !method()->is_static()) { GraphKit kit(_caller); ! kit.null_check_receiver(method()); _caller = kit.transfer_exceptions_into_jvms(); } assert(method() != NULL, "parser must have a method"); ###@###.### 2004-03-11 The last paragraph of the previous diff needs amendment, I think. ************* * 957,965 **** // If this is an inlined method, we may have to do a receiver null check. if (_caller->has_method() && is_normal_parse() && !method()->is_static()) { GraphKit kit(_caller); ! Node* receiver = kit.argument(0); ! kit.do_null_check(receiver, T_OBJECT); _caller = kit.transfer_exceptions_into_jvms(); } assert(method() != NULL, "parser must have a method"); --- 957,973 ---- // If this is an inlined method, we may have to do a receiver null check. if (_caller->has_method() && is_normal_parse() && !method()->is_static()) { GraphKit kit(_caller); ! kit.null_check_receiver(method()); _caller = kit.transfer_exceptions_into_jvms(); + if (kit.stopped()) { + _exits.add_exception_states_from(_caller); + _exits.set_jvms(_caller); + return NULL; + } } assert(method() != NULL, "parser must have a method"); Note especially the "add_exception_states_from" line, which is new in Tiger also. ------------------------------------------ ###@###.### 2004-03-11 About John's suggestion. I tryed it. With this additional "if() {}" we we will have the problem described at the end of the comment section. The small test case (the one at the end of the comment section) will fail if you just add this 'if' into create_entry_map() without changes in graphKit.cpp & graphKit.hpp. The changes in graphKit are the addition of the class BuildCutout and the next replacement: < // Must throw exception, fall-thru not possible? < if (iftrue == top()) { < stop(); < return top(); // No result < } --- > // Must throw exception, fall-thru not possible? > if (stopped()) { > return top(); // No result > } I would like to keep my suggested fix for Mantis.
11-06-2004
WORK AROUND ###@###.### 2004-03-04 Exclude from compilation the method com/sapportals/portal/prt/util/StringUtils escapeToJS
04-03-2004
EVALUATION ###@###.### 2004-03-04 According to the log file and the core file the problem occurs after deoptimization the method: com/sapportals/portal/prt/util/StringUtils escapeToJS ###@###.### 2004-03-04 Duplicate of 4692404 which was just fixed in 1.5.0. See Suggested Fix for 1.4.2_04 diffs.
04-03-2004