JDK-6485361 : C2 compiler crashes while optimizing in 1.4.2_11
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2,1.4.2_11
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8,solaris_10
  • CPU: sparc
  • Submitted: 2006-10-24
  • Updated: 2014-02-27
  • Resolved: 2006-11-14
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_15Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Customer reports a C2 compiler crash which they see with an appserver
under heavy load (Sol. 10, sparc, 1.4.2-11):



(dbx) where
current thread: t@8
=>[1] _lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xff340f90 
  [2] raise(0x6, 0x0, 0xff324a98, 0xffffffff, 0xff368284, 0x6), at 0xff2dfd78 
  [3] abort(0x0, 0x1, 0xff0a8d54, 0xa83f0, 0xff36b298, 0x0), at 0xff2bff98 
  [4] os::abort(0x1, 0xff167ff9, 0x1, 0x80808080, 0xff0000, 0x80808080), at 0xff0a2c5c 
  [5] VMError::report_and_die(0xff17e308, 0xff17e317, 0xff17e327, 0xff141b93, 0x5e, 0xe0000000), at 0xff108228 
  [6] report_fatal_vararg(0xff141b93, 0x5e, 0xff141bd9, 0xff141b7c, 0xfed1e4b4, 0x1628768), at 0xfef81928 
  [7] CodeBuffer::CodeBuffer(0xff192000, 0x0, 0xc00, 0x1000, 0x400, 0x0), at 0xfed82c28 
  [8] Compile::Fill_buffer(0xa91ff500, 0xcd7cf4, 0x160, 0x2c0, 0x6c5b50, 0xd5b254), at 0xfedd531c 
  [9] Compile::Output(0x7, 0xc98af4, 0xb, 0x0, 0x0, 0x0), at 0xfeddb264 
  [10] Compile::Code_Gen(0xa91ff500, 0xff143c60, 0xa91ff414, 0xff192000, 0x0, 0x0), at 0xfedd45e4 
  [11] Compile::Compile(0xff143a95, 0xdbd34, 0x35b5fc, 0x10c2508, 0xffffffff, 0x1), at 0xfee021c4 
  [12] C2Compiler::compile_method(0x358a8, 0xa91ffd1c, 0x0, 0x6eeeb8, 0xffffffff, 0x0), at 0xfedfe924 
  [13] CompileBroker::invoke_compiler_on_method(0x1391, 0x0, 0xffffffff, 0xff1d16e0, 0xff1debc8, 0xf5ab0), at 0xfedfe0e8 
  [14] CompileBroker::compiler_thread_loop(0xff1442e8, 0xff1d1ac4, 0xf5ab0, 0xf6068, 0x3269e4, 0xfee6b580), at 0xfeeae3a8 
  [15] JavaThread::run(0xf5ab0, 0x8, 0x40, 0x0, 0x40, 0x1), at 0xfee6b5a8 
  [16] java_start(0xf5ab0, 0xa9200000, 0x0, 0x0, 0xff0a21d8, 0x1), at 0xff0a230c

Comments
EVALUATION This is a duplicate of the path covered by 4925292: 239 % p 6485361/decode-c++-142 --------------- T H R E A D --------------- Current thread (0x000f5ab0): JavaThread "CompilerThread0" daemon [_thread_in_native, id=8] Stack: [0xa9000000,0xa9200000), sp=0xa91fe898, free space=2042k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x507e88];; void VMError::report_and_die()+0x5e0 V [libjvm.so+0x381930];; void report_fatal_vararg(const char*,int,const char*,...)+0x54 V [libjvm.so+0x182c30];; CodeBuffer::CodeBuffer(int,int,int,int,int,int,BufferBlob*,relocInfo*,RelocateBuffer*,int ,OopRecorder*,const char*,int)+0xc8 V [libjvm.so+0x1d5324];; void Compile::Fill_buffer()+0x150 src/share/vm/opto/output.cpp: 661 // nmethod and CodeBuffer count stubs as part of method's code. 662 _code_buffer = new CodeBuffer(code_req, locs_req, stub_req, const_req, 0, 663 false, 0, 0, 0, true /* Auto Free the buffer */, 664 NULL, NULL, labels_not_set); 665 V [libjvm.so+0x1db26c];; void Compile::Output()+0x8f0 src/share/vm/opto/output.cpp: 134 135 BuildOopMaps(); 136 137 Fill_buffer();
14-11-2006

EVALUATION The VM is crashing because it can not allocate a CodeBuffer. See line 94 of codeBuffer.cpp. Bug 4925292 fixed this problem in 5.0, allowing the VM to recover from the problem instead of failing "hard". Customer's problem is likely to be fixed by backporting that change.
24-10-2006