Bug ID: JDK-4780201 REGRESSION : 1.3.1_06 C2 crashes while widen the range check of an IF node

Versions (Unresolved/Resolved/Fixed)

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.3.1_08 08Fixed

Customer Problem Description:
-----------------------------
We are seeing several VM crashes while deploying J2EE CTS jdbc tests
on Sybase App Server (on both Windows XP Professional version 2002 and Windows NT SP6). The crash does not seem to happen with C1 or with -Xint flag. The crash is not seen with JDK 1.3.1_01 Server or Client VM.

We also tried jdk1.3.1_01 and jdk1.4.1_01 with both server and client VM. Only jdk1.3.1_06-b01 server has this problem. It hit this problem very consistently.
I tried 6 times and hit the problem 5 times.

I could start EAServer inside VC++ but it changed the timing and could not reproduce the problem that way. Neither could I reproduce the problem running debug version.

I tried it 5 times with 1.3.1_06 -Xint and the problem did not show up.

Here is the stack trace. I got few stack traces and they all
have the same lines.

adjust_check(Node * 0x04508c38, Node * 0x04dacf48, Node * 0x0450968c, int 1, int 
1, PhaseIterGVN * 0x041ff3f0) line 447 + 32 bytes
IfNode::Ideal(PhaseGVN * 0x041ff3f0, PhaseDefUse * 0x041ff510) line 652 + 29 
bytes
PhaseIterGVN::transform_old(Node * 0x04dacfb4) line 793 + 27 bytes
PhaseIterGVN::optimize() line 705 + 15 bytes
Compile::Optimize() line 916
Compile::Compile(ciEnv * 0x041ffe4c, ciScope * 0x01badeb4, ciMethod * 
0x01baddc8, int -1, long 1, long 0) line 407
C2Compiler::compile_method(ciEnv * 0x041ffe4c, ciScope * 0x01badeb4, ciMethod * 
0x01baddc8, int -1, long 0) line 31
CompileBroker::invoke_compiler_on_method(CompileTask * 0x04ed68c0) line 1132
CompileBroker::compiler_thread_loop() line 1039 + 9 bytes
compiler_thread_entry(JavaThread * 0x01b80800, Thread * 0x01b80800) line 2107
JavaThread::thread_main_inner() line 1162 + 18 bytes
JavaThread::run() line 1149
_start(Thread * 0x01b80800) line 236
MSVCRT! 77c37fb8()
KERNEL32! 77e802ed()


Attached is the log from -XX:+PrintCompilation

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_08 FIXED IN: 1.3.1_08 INTEGRATED IN: 1.3.1_08

14-06-2004

EVALUATION ###@###.### 2002-11-18 Initial investigation showed this to be the problem. Waiting for more details from the customer. This is happening when during compilation, an attempt is made to widen the range check of an IF node as part of IFNode::Ideal(). The IF node in question here is dominating other range tests below. This optimization will remove the dominated checks and at the same time expand the test range for dominator IFNode.

11-06-2004

SUGGESTED FIX ###@###.### 2002-11-18 This probably results from the following diff between 1.3.1_06 and 1.4 in ifnode.cpp adjust_check() *** 431,436 **** --- 419,425 ---- // Break apart the old check Node *iff = proj->in(0); Node *bol = iff->in(1); + if( bol->is_top() ) return; // In case a partially dead range check appears Node *cmp = bol->in(1); // Compute a new check Note that implementation of bol->is_top() in 1.3.1_06 would be done as: + if( bol == gvn->C->_top_node ) return; // In case a partially dead range check appears ----- -----

11-06-2004