JDK-6583812 : The fix for 5053921 might be incomplete or cause another problem in 1.3.1_14 and later version
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.3.1_20
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2007-07-23
  • Updated: 2010-08-05
  • Resolved: 2007-09-20
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_21 b01Fixed
Related Reports
Relates :  
JDK-5053921 - Application crashes using :XX+UseTLE and -server on Windows
Description
A customer faces with critical crash(SIGSEGV) issue in Solaris box.
That occurs in 1.3.1_14 and later.
When they backed out the fix for 5053921, their crash come not to occur
even in 1.3.1_14.

=== Customers Requests ====
R1 Is there any possibility that the fix for 5053921  causes their crash ?
   (As to "their crash", please see the report attached to this CR )
   If so, please resolve and provide the fix.
R2 If it is difficult to resolve their  crash,
   please clarify whether or not 5053921 occur only in Windows box with -XX:-UseTLE (and -server ) ?
R3 If they  try to back out the src fix for 5053921,
   Could you please let us know what Sun can predict perspective of what will happen ?
   Just thought or feelings is o.k
==========================
Comments
SUGGESTED FIX With context.... --- chaitin.cpp Fri Aug 17 17:26:14 2007 *************** *** 1759,1769 **** --- 1759,1776 ---- return derived; } // Derived is NULL+offset? Base is NULL! + uint i; if( derived->is_Con() ) { Node *base = new (1) ConPNode( TypePtr::NULL_PTR ); uint no_lidx = 0; // an unmatched constant in debug info has no LRG _names.extend(base->_idx, no_lidx); derived_base_map[derived->_idx] = base; + Block *b = _cfg._bbs[derived->_idx]; + for( i = 1; i < b->end_idx(); i++ ) { + if ( b->_nodes[i] == derived) break; + } + b->_nodes.insert( i, base ); + _cfg._bbs.map(base->_idx, b); return base; } *************** *** 1778,1784 **** // Recursively find bases for Phis. // First check to see if we can avoid a base Phi here. Node *base = find_base_for_derived( derived_base_map, derived->in(1),maxlrg); - uint i; for( i = 2; i < derived->req(); i++ ) if( base != find_base_for_derived( derived_base_map,derived->in(i),maxlrg)) break; --- 1785,1790 ---- *************** *** 1891,1897 **** Node *derived = lrgs(neighbor)._def; const TypePtr *tj = derived->bottom_type()->isa_ptr(); // If its an OOP with a non-zero offset, then it is derived. ! if( tj && tj->_offset != 0 && tj->isa_oop_ptr()) { Node *base = find_base_for_derived( derived_base_map, derived, maxlrg ); assert( base->_idx < _names.Size(), "" ); // Add reaching DEFs of derived pointer and base pointer as a --- 1897,1903 ---- Node *derived = lrgs(neighbor)._def; const TypePtr *tj = derived->bottom_type()->isa_ptr(); // If its an OOP with a non-zero offset, then it is derived. ! if( tj && tj->_offset != 0 && (tj->isa_oop_ptr() || derived->is_Con()) ) { Node *base = find_base_for_derived( derived_base_map, derived, maxlrg ); assert( base->_idx < _names.Size(), "" ); // Add reaching DEFs of derived pointer and base pointer as a
20-08-2007
SUGGESTED FIX The suggested fix below has been verified locally by inspecting the PrintOptoAssembly oopMaps for the modified getVerb method in the test case. The register holding the NULL+8 value is no longer marked as an oop in the oopMaps. ------- chaitin.cpp ------- 1761a1762 > uint i; 1766a1768,1773 > Block *b = _cfg._bbs[derived->_idx]; > for( i = 1; i < b->end_idx(); i++ ) { > if ( b->_nodes[i] == derived) break; > } > b->_nodes.insert( i, base ); > _cfg._bbs.map(base->_idx, b); 1781d1787 < uint i; 1894c1900 < if( tj && tj->_offset != 0 && tj->isa_oop_ptr()) { --- > if( tj && tj->_offset != 0 && (tj->isa_oop_ptr() || derived->is_Con()) ) {
18-08-2007
EVALUATION The oops_do function is stopped on an oop which has the value "8", which the JIT unfortunately generates as the address of the length field of a NULL array object. (More recent JITs avoid doing that.) It appears that the failure is a direct result of the fix for 5053921. That fix causes NULL+8 style pointers to be not recognized as derived. Instead, NULL+8 avoided during derived oop discovery, and therefore is later perceived as a "plain" oop, eventually causing the failure during oops_do. This bug should not be confused with 4645614, which has the same failure mode, but has a different cause.
18-08-2007