JDK-6179233 : 1.4.2_06 crashes when setting -XX:CompileThreshold=200 -server on Windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_05
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2004-10-14
  • Updated: 2019-05-08
  • Resolved: 2004-12-10
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_08 b01Fixed
Related Reports
Relates :  
Relates :  
Description
The VM crashes on Linux and Windows with
-XX:CompileThreshold=200 and the following method (class attached) causes a
      
crash of the JVM com/sapportals/portal/prt/jndisupport/util/
AbstractHierarchicalContext

lookup The crash happens on Windows and Linux (both x86), other platforms      
not tested. Excluding this method from JIT seems to prevent the crash. On
Windows, the crash seems to be reproducible all the time with the following
 

Java Error ID: # Java VM: Java HotSpot(TM) Server VM (1.4.2_05-b04 mixed
      
mode) # # Error ID: 4255494C442F4F502D41500E4350500107 # # Problematic Thread:
prio=1 tid=0x08b5aa18 nid=0x3f54 runnable also see attached Windows_crash.txt
 
for crash transcript. The JVM on Linux sometimes crashes with the above
      
error id, sometimes it crashes without error id. Please see the attached
Linux_crash.txt transcript.
###@###.### 10/14/04 16:41 GMT



------------------------------------------
Please pull the Dr. Watson dump from
http://sap-jtc.germany.sun.com/transfer/cr6179233/20041014

Stefan Schneider
###@###.### 10/15/04 00:40 GMT
------------------------------------------
Three other crash scenarios are shown here:

http://sap-jtc.germany.sun.com/transfer/cr6179233/20041018/crash1
http://sap-jtc.germany.sun.com/transfer/cr6179233/20041018/crash2
http://sap-jtc.germany.sun.com/transfer/cr6179233/20041018/crash3

The files from each of these crashes are attached as follows:

Crash 1: AbstractHierarchicalContext.java, Windows_crash.txt and Linux_crash.txt
Crash 2: WSConfigurationHandler.java
Crash 3: PortalServiceItem.java
###@###.### 10/19/04 16:26 GMT

------------------------------------------

The customer has hinted that excluding PortalServiceItem.startServices from compilation avoids all failures. We are hoping for confirmation of this workaround.
###@###.### 10/19/04 16:27 GMT

Comments
SUGGESTED FIX --- chaitin.cpp Mon Nov 29 06:07:11 2004 *************** *** 1403,1409 **** // Search the current block for an existing base-Phi Block *b = _cfg._bbs[derived->_idx]; ! for( i = 1; i < b->end_idx(); i++ ) {// Search for matching Phi Node *phi = b->_nodes[i]; if( !phi->is_Phi() ) { // Found end of Phis with no match? b->_nodes.insert( i, base ); // Must insert created Phi here as base --- 1403,1409 ---- // Search the current block for an existing base-Phi Block *b = _cfg._bbs[derived->_idx]; ! for( i = 1; i <= b->end_idx(); i++ ) {// Search for matching Phi Node *phi = b->_nodes[i]; if( !phi->is_Phi() ) { // Found end of Phis with no match? b->_nodes.insert( i, base ); // Must insert created Phi here as base ###@###.### 2004-12-02 18:33:49 GMT
02-12-2004

EVALUATION The VM crashes for the customer in at least two ways, so there may be multiple bugs. The user.dmp and "crash3" appear to be the same, with C2 failing in reg_split.cpp, per the analysis found in the Comments section. At the time, C2 was compiling PortalServiceItem.startServices. That analysis indicates the same bug as 4965984, now closed. In 4965984, the customer accepted the workaround as a solution, and was not motivated to help us pursue a fix. The source code for PortalServiceItem.startServices (attached) shows a method that is very similar in structure to the failing method for 5026838 (to be fixed in 1.4.2_07). It may be worth our while to have the customer, if willing, attempt a run with an early 1.4.2_07 build, or, a custom built 1.4.2_06 with the fix for 5026838 added. The "crash1" failure is a guarantee failure at buildOopMap.cpp:263. It is not clear if, or how this related to "crash3". The method of failure "crash2" is unknown for now. It could be either the buildOooMap or the reg_split failure. ###@###.### 10/19/04 16:26 GMT This may an off-by-one error fixed in Tiger in chaitin.cpp under the bugid of 5030922. The bugtraq entry for that bug has no relevant info; I'm working with the RE for that bug to correct the situation. ###@###.### 2004-11-29 14:27:05 GMT Customer verifies that the off-by-one fix from 5030922 eliminates their problem. I will leave this bug open since 5030922 was an umbrella bug which contained other fixes. The fix should be applied to 5.0, also. ###@###.### 2004-12-02 18:33:49 GMT
19-10-2004