JDK-4890651 : Crash in OopFlow::build_oop_map
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8.0pe,1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2003-07-15
  • Updated: 2003-09-16
  • Resolved: 2003-08-12
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_02 02Fixed
Related Reports
Relates :  
JDK-4827295 - VM assertion failure in SunOne Appserver7 on solsparc
Description
Running SPECjAppServer on SunOne AppServer 8.0 build 25 using JDK 1.4.2 build 28 about 40% of the time during the first few minutes of a run. The core file shows this stack trace:

current thread: t@17
=>[1] __sigprocmask(0x0, 0x823ff8c8, 0x0, 0x0, 0x0, 0x0), at 0xff369764 
  [2] _resetsig(0xff36bf60, 0x0, 0x0, 0x82401d70, 0xff37e000, 0x0), at 0xff35e970 
  [3] _sigon(0x82401d70, 0xff385930, 0x6, 0x823ff99c, 0x82401d70, 0x6), at 0xff35e110 
  [4] _thrp_kill(0x0, 0x11, 0x6, 0xff37e000, 0x11, 0xff2c0440), at 0xff361150 
  [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2c03ac, 0x4), at 0xff24b944 
  [6] abort(0xff2bc000, 0x823ffaf0, 0x0, 0xfffffff8, 0x4, 0x823ffb11), at 0xff2358e4 
  [7] os::abort(0x1, 0xfe54cdd3, 0x823ffb90, 0x635f, 0xfe47f120, 0xb), at 0xfe480a90 
  [8] os::handle_unexpected_exception(0x4aad70, 0xb, 0xfe15c004, 0x824008c8, 0xb, 0x0), at 0xfe47f1ec 
  [9] JVM_handle_solaris_signal(0xfe15c004, 0x824008c8, 0x82400610, 0x4000, 0x4164, 0x0), at 0xfe1ed234 
  [10] __sighndlr(0xb, 0x824008c8, 0x82400610, 0xfe1ec948, 0x82401e14, 0x82401e04), at 0xff36b824 
  [11] sigacthandler(0xb, 0x82401d70, 0x0, 0x0, 0x0, 0xff37e000), at 0xff3684d8 
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [12] OopFlow::build_oop_map(0x1a, 0xf2db8c, 0x6c, 0xf0fb30, 0xd8, 0xf2db7c), at 0xfe15c004 
  [13] OopFlow::compute_reach(0x24, 0xffffffff, 0x4c, 0xfffffffe, 0xf2db7c, 0xf2db7c), at 0xfe121fb8 
  [14] Compile::BuildOopMaps(0x4a9608, 0xf0c3d0, 0x162, 0x2c4, 0x7ce414, 0x4a3bf8), at 0xfe1ea4f8 
  [15] Compile::Output(0x824012b0, 0x0, 0xb, 0x0, 0x0, 0x0), at 0xfe1edbc4 
  [16] Compile::Code_Gen(0x824012b0, 0x82401084, 0x824011c4, 0x1a7864, 0x824011c4, 0x0), at 0xfe1e71e4 
  [17] Compile::Compile(0x56eb4c, 0xe5862c, 0x0, 0xe1c360, 0xffffffff, 0x1), at 0xfe216a60 
  [18] C2Compiler::compile_method(0x4ab8a8, 0x82401aa8, 0x0, 0xe1c360, 0xffffffff, 0x0), at 0xfe21347c 
  [19] CompileBroker::invoke_compiler_on_method(0x2f6, 0x0, 0xffffffff, 0x4aadfc, 0xfe5c907c, 0x4aad70), at 0xfe212cbc 
  [20] CompileBroker::compiler_thread_loop(0x4aad70, 0x4aad70, 0x499cb8, 0x4ab310, 0x30603c, 0xfe283eac), at 0xfe2cad58 
  [21] JavaThread::run(0x4aad70, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe283ed4 
  [22] _start(0x4aad70, 0xff37f688, 0x1, 0x1, 0xff37e000, 0x0), at 0xfe280320

The VM is run with these arguments:
-server -XX:+AggressiveHeap -Xms1800m -Xmx1800m -Xmn1400m -Xss128k -verbose:gc -XX:-StackTraceInThrowable -XX:+DisableExplicitGC
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger FIXED IN: 1.4.2_02 tiger INTEGRATED IN: 1.4.2_02 tiger tiger-b15 tiger-b16 tiger-b19
14-06-2004
SUGGESTED FIX A sufficient fix for this bug in 1.4.2 is below, but the tiger fix could be expanded to do some cleanup in this area. ------- lcm.cpp ------- 753c753 < Node_List *out = new Node_List(Thread::current()->resource_area()); --- > Unique_Node_List *out = new Unique_Node_List(Thread::current()->resource_area()); ###@###.### 2003-07-30
30-07-2003
WORK AROUND Use the following .hotspot_compiler directive: exclude com/sun/jts/pi/InterceptorImpl receive_request_service_contexts ###@###.### 2003-07-24
24-07-2003
EVALUATION This bug is a more reproducible version of 4827295. Build_oop_map() is failing because it can't find a def corresponding to a use. Specifically, it encounters an oop phi node with a NULL input. The phi input turns null during register allocation when a redundant copy placed by insert_copies() is eliminated in the subsequent build_ifg_physical() pass. The redundant copy had been placed because the live ranges for two (nearly identical) phi nodes had been merged during aggressive coalescing. Yet, both phis remained alive and did not conflict because one had no output edges. Both phi nodes were created in GCM during the catch_call_cleanup phase. The phi node with no uses was created because a single call node used the original (pre-cloned) node multiple times, causing it to be put on the out list more than once. The second cloning has no uses because the first cloning took care of both uses. This problem can be solved by changing the Node_List "out" in catch_call_cleanup to a "Unique_Node_List". Further investigation is needed to determine if the call node with multiple uses is actually a legal graph. ###@###.### 2003-07-24 We can do some housekeeping improvements in catch_call_cleanup() to avoid creation of duplicate phi nodes there. ###@###.### 2003-07-30
24-07-2003