JDK-6252713 : C2 compiler crash at ciTypeFlow::flow_types
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_05
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: x86,sparc
  • Submitted: 2005-04-08
  • Updated: 2010-05-10
  • Resolved: 2005-05-28
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.
1.4.2_09 b02Fixed
Related Reports
Relates :  
Customer is running Sol 9 on SunV60s X86 machines
They have been experiencing more frequent crashes the last couple weeks and it peaked at 30 crashes in 2 hours.

Stack from core file is
(dbx) lwp l@14
t@null (l@14) stopped in _lwp_kill at 0xc46cf317
0xc46cf317: _lwp_kill+0x000c:   jae      _lwp_kill+0xf  [ 0xc46cf31a, .+3 ]
(dbx) where
=>[1] _lwp_kill(0xe, 0x6), at 0xc46cf317 
  [2] pthread_kill(0xe, 0x6), at 0xc4769cdd 
  [3] raise(0x6), at 0xc46e7a9d 
  [4] abort(0xc451864c, 0xc44ba000, 0x0, 0x0, 0x0, 0x0), at 0xc46d012e 
  [5] os::abort(0x1), at 0xc43cf3b0 
  [6] report_error(0x1, 0xc4454890, 0xa2d, 0xc446726c, 0xc4467260, 0x581fe8b0), at 0xc42d3a54 
  [7] report_fatal(0xc4454890, 0xa2d, 0xc4454878), at 0xc42d3409 
  [8] ciTypeFlow::flow_types(0xab11928), at 0xc41458ce 
  [9] ciTypeFlow::do_flow(0xab11928), at 0xc4145533 
  [10] ciMethod::get_osr_flow_analysis(0x8c09948, 0x5759), at 0xc41ef137 
  [11] Parse::Parse(0x581ff180, 0x98e54c8, 0x8c09948, 0x45134000), at 0xc412d864 
  [12] ParseGenerator::generate(0x9d83794, 0x98e54c8), at 0xc412dcf2 
  [13] Compile::Compile(0x581ff8e4, 0x581ffd2c, 0x0, 0x8c09948, 0x5759, 0x1, 0x0), at 0xc42be65d 
  [14] C2Compiler::compile_method(0x80720c8, 0x581ffd2c, 0x0, 0x8c09948, 0x5759, 0x0), at 0xc4297701 
  [15] CompileBroker::invoke_compiler_on_method(0x9927e40), at 0xc418fe37 
  [16] CompileBroker::compiler_thread_loop(0xc44ba000, 0x581fffa8, 0xc41c472d, 0x826c7f8, 0x826c7f8, 0x6), at 0xc4201b2f 
  [17] compiler_thread_entry(0x826c7f8, 0x826c7f8), at 0xc42011c5 
  [18] JavaThread::thread_main_inner(0x826c7f8), at 0xc41c472d 
  [19] JavaThread::run(0x826c7f8), at 0xc41c4048 
  [20] _start(0x826c7f8), at 0xc41c19f2 
  [21] _thr_setup(0xc4691a00), at 0xc4774513 
  [22] _lwp_start(), at 0xc4774790 
(dbx) frame 14
0xc4297701: compile_method+0x00c7:      addl     $0x0000001c,%esp

extracted the class and method to be
(dbx) x 0x8c09948 + 0x14
dbx: warning: unknown language, 'c' assumed
0x08c0995c:      0x08c09998
(dbx) x 0x08c09998+4
0x08c0999c:      0x0826f820
(dbx) x 0x0826f820
0x0826f820:      0xbad7f438
(dbx) print (char*) 0xbad7f438+14
((char *) 0xbad7f438U)+14 = 0xbad7f446 "_jspService"
(dbx) x 0x8c09948+0x18
0x08c09960:      0x08c099a8
(dbx) x 0x08c099a8+0x14
0x08c099bc:      0x08c099f8
(dbx) x 0x08c099f8+4
0x08c099fc:      0x0826f828
(dbx) x 0x0826f828
0x0826f828:      0xbb5d5d00
(dbx) print (char*) 0xbb5d5d00 + 14
((char *) 0xbb5d5d00U)+14 = 0xbb5d5d0e "org/apache/jsp/cart_jsp"

###@###.### 2005-04-08 18:31:16 GMT

SUGGESTED FIX see http://jpsesvr.sfbay:8080/ctetools/html/ViewDetail.jsp?index=1441 ###@###.### 2005-05-03 01:01:18 GMT

EVALUATION We simplfied and upgraded failure reporting for CI as part of the fix for 4833712 in 5.0. Will investigate the ease of backporting those changes. ###@###.### 2005-04-15 22:44:13 GMT Looking more closely at the changes for 4833712, it appears that those changes should address the customer's problem. Unfortunately, that bugfix was not a point fix, so the backport may not be as simple as we'd like. Customer may want to try a 5.0 VM in a 1.4.2 JDK to first verify that the problem is solved. Otherwise, the debug cycle may be more lengthy. Reassigning to sustaining for consideration for a 1.4.2 update. ###@###.### 2005-04-18 17:19:35 GMT When initial block cannot be found in _blocks, the following guarantee will fail definitely. At this time, it is seen already too many basic blocks present, according to logging in tiger, set bailout and return. Since we dont have the apprehensive logging mechanism in 142, here set bailout in ciEnv, and return. Meanwhile remove the watching point at do_method_entry due to removing of setting uncommon_trap. Also add watching points to check if bailout. ###@###.### 2005-05-03 01:01:17 GMT