Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6207079

Hotspot client compiler overfills CodeBuffer: crashes when deoptimizing.



    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 1.4.2_06
    • Fix Version/s: 6
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:



        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


            Issue Links



                kbr Kenneth Russell (Inactive)
                kevinw Kevin Walls
                0 Vote for this issue
                1 Start watching this issue