JDK-6973963 : SEGV in ciBlock::start_bci() with EA
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs19
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2010-08-02
  • Updated: 2011-04-23
  • Resolved: 2011-04-23
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.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Duplicate :  
JDK-6970460 - SIGSEGV in ciTypeFlow::flow_block compiling sun.security.provider.NativePRNG$RandomIO.implNextBytes
Relates :  
JDK-6975078 - assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()
Relates :  
JDK-6968368 - SIGSEGV in the BCEscapeAnalyzer::copy_dependencies(Dependencies*)+0x105
Description
An other case similar to 6968368. BCEscapeAnalyzer::do_analysis() calls ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. This constructor allocates GrowableArray elements on stack (thread local resource area):

_blocks =  new(_arena) GrowableArray<ciBlock *>(block_estimate);

As result when the method recompiled without EA _blocks->_data is NULL.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e35fa8ebccd
14-08-2010
PUBLIC COMMENTS Added new debug flag SubsumeLoads to control subsumed loads generation. Added new debug flag StressRecompilation to recompile with subsume_loads = false and do_escape_analysis = false. Added more checks into ResourceObj and growableArray to verify correctness of allocation type. I have to relax the new assert in GrowableArray when elements are allocated on arena to allow allocattion of GrowableArray object as a part of an other object (for example, in ConnectionGraph and SuperWord). Added ResourceObj destructor to zap _allocation field. Added assert into get_allocation_type() to check that 'this' address is still encoded in _allocation. Found several cases where it was not true, have to add copy constructor and assignment operator. Moved all new methods with asserts into allocation.cpp. The added assert failed for CodeBuffer since it destroys itself inside destructor before ResourceObj destructor called. I save/restore allocation type around Copy::fill_to_bytes() in ~CodeBuffer() to solve this problem. Replaced PhaseCFG::_node_latency field with pointer since it is valid only inside resource mark in GlobalCodeMotion().
04-08-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e35fa8ebccd
04-08-2010