JDK-6207079 : Hotspot client compiler overfills CodeBuffer: crashes when deoptimizing.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_06
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2004-12-10
  • Updated: 2010-05-05
  • Resolved: 2005-02-01
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 JDK 6
1.4.2_08Fixed 6 b22Fixed
Related Reports
Relates :  
Relates :  
Description
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

Comments
EVALUATION The compiler needed an additional check_codespace() call during emission of the OSR entry. The fix is simple and can be backported to update releases. As a workaround a .hotspot_compiler file can be created in the current working directory of the application containing the line exclude G02IO004 makDetailDm ###@###.### 2005-1-21 02:49:05 GMT
21-01-2005

WORK AROUND Interpreted mode, -Xint. If using -client VM, find the problem Java method, and exclude it. In this case: $ cat .hotspot_compiler exclude G02IO004 makDetailDm Or, use the -server VM: the server VM has not been seen to compile the problem method, although no detail is given by -XX:+PrintCompilation in 1.4.2. In 1.5.0 the server VM explicitly refuses to compile the problem method - possibly on grounds of taste. -XX:+PrintCompilation output: 1% b G02IO004v2::makDetailDm @ 7692 (20325 bytes) 1 COMPILE SKIPPED: out of nodes parsing method (not retryable) ###@###.### 2004-12-10 14:19:42 GMT
10-12-2004

SUGGESTED FIX The other bugs mentioned bail out of the compile when they realise there is not enough room in the CodeBuffer. ###@###.### 2004-12-10 14:19:42 GMT
10-12-2004