Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2122882 | 5.0u3 | Kenneth Russell | P3 | Resolved | Fixed | b04 |
JDK-2122797 | 1.4.2_08 | Lew Yobs | P3 | Resolved | Fixed | b02 |
Java's Hotspot client compiler is compiling methods that perhaps it should not attempt. This results in a crash if the VM has to generate a stacktrace involving that compiled method, or an assertion during the compile in java_g.
The testcase throws an exception involving the c1-compiled method, the native stack for that crash is:
---- called from signal handler with signal 11 (SIGSEGV) ------
[8] CodeCache::make_marked_nmethods_zombies(0x0, 0x25b380, 0x10, 0x10, 0x58b2063e, 0xfe37fd50), at 0xfed9efec
[9] VM_Deoptimize::doit(0xffbfdec8, 0x28def0, 0x0, 0x2e835d28, 0xfeffa000, 0xfe37fd30), at 0xfed9ed18
[10] VM_Operation::evaluate(0xffbfdec8, 0x28e068, 0xfeffa000, 0x36c80, 0x3a6e7c, 0xfed68ff0), at 0xfed6c198
[11] VMThread::evaluate_operation(0xc7388, 0xffbfdec8, 0x4a20, 0x4800, 0x4b3c, 0x0), at 0xfed6c018
[12] VMThread::loop(0x4000, 0x3c00, 0x3f3c, 0x3c00, 0x3ee4, 0x3800), at 0xfecc6fe4
[13] VMThread::run(0xc7388, 0x0, 0xff019478, 0xffff8000, 0x0, 0x0), at 0xfecc69ac
[14] _start(0xc7388, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfecc6898
This is happening in the VMThread, while the thread running the actual java code is performing a printStackTrace() call.
The java_g assertion:
# HotSpot Virtual Machine Error, assertion failure
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03-debug mixed mode)
#
# assert(end >= _instsStart && end <= _instsOverflow, "CodeBuffer overflow")
#
# Error ID: /export1/jdk142-update/ws/fcs/hotspot/src/share/vm/asm/codeBuffer.hpp, 277 [ Patched ]
#
# Problematic Thread: prio=5 tid=0x00104bd0 nid=0x7 runnable
#
...has been seen before, e.g. in bugs 4458038 and 4345058.
The above are from 1.4.2_06. With 1.4, java -Xcomp CLASS or -Xdebug CLASS reproduces the problem for the attached class (using -client).
However, the same problem is happing in 1.5.0. In 1.5.0, simply "java -client CLASS" gives a crash:
current thread: t@1
=>[1] _lwp_kill(0x0, 0x6, 0x0, 0xff33c000, 0x37bc0, 0x341c), at 0xff31f27c
[2] raise(0x6, 0x0, 0xffbfc740, 0x4f04, 0x4c00, 0x5800), at 0xff2d04c8
[3] abort(0x348f0, 0x348f0, 0x0, 0xff0dd9dc, 0xff0b6000, 0xff0e1018), at 0xff2b6c70
[4] os::abort(0x1, 0x4e40, 0xfd04c, 0x1b1, 0xff0b6000, 0x4c00), at 0xfefb9004
[5] VMError::report_and_die(0x0, 0xff0d3f08, 0x4000, 0xfefbc704, 0xff03795a, 0xfefbc704), at 0xff031a74
[6] crash_handler(0xb, 0x0, 0xffbfcb00, 0x0, 0x0, 0x0), at 0xff031e58
[7] __sighndlr(0xb, 0x0, 0xffbfcb00, 0xff031e14, 0x0, 0x0), at 0xff3761a0
---- called from signal handler with signal 11 (SIGSEGV) ------
[8] frame::print_on_error(0xffbfd090, 0xff06d44c, 0xff0dca10, 0x7d0, 0xffbfce90, 0xf8c6eb48), at 0xfee9b56c
[9] VMError::report(0xffbfd090, 0xffffffba, 0xffbfd9c8, 0x37bf0, 0xff0a0e26, 0x7d0), at 0xff030874
[10] VMError::report_and_die(0xffbfd160, 0xff0d3f08, 0xff0d3f40, 0x0, 0x4000, 0xffbfd9c8), at 0xff0313b8
[11] crash_handler(0xb, 0x0, 0xffbfd358, 0x0, 0x0, 0x0), at 0xff031e58
[12] __sighndlr(0xb, 0x0, 0xffbfd358, 0xff031e14, 0x0, 0x0), at 0xff3761a0
---- called from signal handler with signal 11 (SIGSEGV) ------
[13] frame::print_on_error(0xffbfd8e8, 0xff06d44c, 0xff0dca10, 0x7d0, 0xffbfd840, 0xf8c6eb48), at 0xfee9b56c
[14] VMError::report(0xffbfd8e8, 0x0, 0xffbfd9c8, 0x1, 0xff0a0e26, 0x7d0), at 0xff030754
[15] VMError::report_and_die(0xffbfd9c8, 0xff0d3f08, 0xff0d3f40, 0x4020, 0x5, 0xffbfd9c8), at 0xff0313b8
[16] JVM_handle_solaris_signal(0xb, 0xffbfdea8, 0xffbfdbf0, 0x5000, 0x6, 0x37bf0), at 0xfedffec8
[17] __sighndlr(0xb, 0xffbfdea8, 0xffbfdbf0, 0xfedff4c0, 0x0, 0x0), at 0xff3761a0
---- called from signal handler with signal 11 (SIGSEGV) ------
[18] CodeCache::find_blob(0xf8c6eb48, 0x67bc, 0x3c8420, 0xf8c05874, 0x6400, 0xff0b6000), at 0xfecedc28
[19] frame::is_osr_adapter_frame(0xffbfe290, 0x4c60, 0xff0d0070, 0x5400, 0x57bc, 0xff0cb764), at 0xfeda0800
[20] frame::sender_with_pc_adjustment(0xffbfe2a0, 0xf8c04fc0, 0xffbfe2b0, 0xffbfe4a8, 0x1, 0xffbfe290), at 0xfecea36c
[21] SharedRuntime::resolve_sub_helper(0xffbfe438, 0x37c94, 0x1, 0x1, 0x0, 0xff0b6000), at 0xfeda0478
[22] SharedRuntime::resolve_helper(0xffbfe4a4, 0x37bf0, 0x1, 0x1, 0x37bf0, 0x5c00), at 0xfeda030c
[23] Runtime1::resolve_opt_virtual_call(0x37bf0, 0xccd6ac10, 0x37bf0, 0x381c8, 0x381cc, 0xff0b6000), at 0xfeda00c4
[24] 0xf8c6eb98(0xccd6ac10, 0x14, 0xb40051, 0x51, 0xb40000, 0xb4), at 0xf8c6eb97
[25] 0xf8c9db00(0xccd6ac10, 0xd0c1e350, 0xffbfe668, 0x38, 0x7, 0x0), at 0xf8c9daff
[26] 0xf8c05874(0xccd6ac10, 0xb6, 0xf8c007c0, 0xf8c148a0, 0x5c00, 0xffbfe608), at 0xf8c05873
[27] 0xf8c05874(0xccd6aba0, 0xb6, 0xffbfe760, 0xf8c14770, 0x7c800000, 0xffbfe688), at 0xf8c05873
[28] 0xf8c05874(0xccd6aba0, 0xb8, 0xffbfe7e4, 0xf8c14720, 0x381b0, 0xffbfe700), at 0xf8c05873
[29] 0xf8c05874(0xccd6abd0, 0x0, 0xff0d0070, 0xf8c149e0, 0x7, 0xffbfe780), at 0xf8c05873
[30] 0xf8c05874(0xccd6aa18, 0x0, 0xff0d0070, 0xf8c14720, 0x7, 0xffbfe820), at 0xf8c05873
[31] 0xf8c05764(0xccd6aa18, 0x0, 0xff0d0070, 0xf8c14770, 0x7, 0xffbfe8a0), at 0xf8c05763
[32] 0xf8c05764(0xc000, 0x2, 0x4800, 0xf8c14720, 0xff0c9408, 0xffbfe950), at 0xf8c05763
[33] 0xf8c00218(0xffbfea38, 0xffbfeb90, 0xa, 0xd0c08980, 0xf8c0a7e0, 0xffbfeb18), at 0xf8c00217
[34] JavaCalls::call_helper(0x1, 0x37bf0, 0xffbfeb10, 0xffbfea48, 0xffbfeb14, 0x0), at 0xfecd96e0
[35] jni_CallStaticVoidMethod(0xff0cfabc, 0xff0d0070, 0x381bc, 0x37bf0, 0x1400, 0x37db8), at 0xfedacb74
[36] main(0xff0cbe4c, 0x32756, 0xfed23a6c, 0x0, 0x0, 0x1d8), at 0x123b4
While a 1.5.0 java_g asserts at the time of compiling the problem method, as 1.4.2 did, and gives the same assertion as in 1.4.2:
# Internal Error (/BUILD_AREA/jdk1.5.0/hotspot/src/share/vm/asm/codeBuffer.hpp, 278 [ Patched ]), pid=28863, tid=6
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-b64-debug mixed mode)
#
# Error: assert(end >= _instsStart && end <= _instsOverflow,"CodeBuffer overflow")
###@###.### 2004-12-10 14:19:42 GMT
- backported by
-
JDK-2122797 Hotspot client compiler overfills CodeBuffer: crashes when deoptimizing.
- Resolved
-
JDK-2122882 Hotspot client compiler overfills CodeBuffer: crashes when deoptimizing.
- Resolved
- relates to
-
JDK-4345058 sun4m: JVM aborts immediately upon startup when "-client -Xcomp" switch is used.
- Resolved
-
JDK-4458038 CTW assertion at codeBuffer.hpp, 179 [ Patched ]
- Closed