United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4890651 Crash in OopFlow::build_oop_map
JDK-4890651 : Crash in OopFlow::build_oop_map

Details
Type:
Bug
Submit Date:
2003-07-15
Status:
Resolved
Updated Date:
2003-09-16
Project Name:
JDK
Resolved Date:
2003-08-12
Component:
hotspot
OS:
solaris_8,generic
Sub-Component:
compiler
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
8.0pe,1.4.2
Fixed Versions:
1.4.2_02 (02)

Related Reports
Backport:
Relates:

Sub Tasks

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
WORK AROUND

Use the following .hotspot_compiler directive:

exclude com/sun/jts/pi/InterceptorImpl receive_request_service_contexts

###@###.### 2003-07-24
                                     
2003-07-24
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
                                     
2003-07-24
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
                                     
2003-07-30
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


                                     
2004-06-14



Hardware and Software, Engineered to Work Together