JDK-6564247 : assert(bb->_end_bci + bc_len == bb[1]._bci,"unmatched bci info in basic block") fails
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-05-31
  • Updated: 2010-04-04
  • Resolved: 2009-02-13
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
6u14Fixed 7Fixed hs14Fixed
Description
While testing the G1 workspace, I came across the following failure:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/generateOopMap.cpp:947
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/java/east/u2/ap31282/hs-g1-fixes/src/share/vm/oops/generateO
opMap.cpp, 947 [ Patched ]), pid=14729, tid=2
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.7.0-internal-fastdebug mixed mod
e)
#
# Error: assert(bb->_end_bci + bc_len == bb[1]._bci,"unmatched bci info in basic
block")
# An error report file with more information is saved as hs_err_pid14729.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

It's very easily reproduced (i.e., it fails every time) with the G1 workspace (G1 doesn't have to be enabled; ParallelGC also causes it too) and running the eclipse benchmark of the dacapo test suite.

Here's how you reproduce it. You need your own copy of the dacapo test suite (it writes a lot to disk, so you do need your copy on a directory you can write to). Copy the jar file from here:

/java/east/u2/ap31282/gc_test_suite/dacapo/dacapo-2006-10.jar

Then, run it this way:

java -d64 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -jar dacapo-2006-10.jar -s default eclipse

I have reproduced it on 4 different platforms:

Solaris SPARC C2 64-bit
Solaris AMD64 C2 
Linux AMD64 C2 64-bit
Linux AMD64 C2

I was not able to reproduce it with a reasonably up-to-date non-G1 workspace.

Comments
SUGGESTED FIX Job ID: 20070628083005.ap31282.hs-g1-fixes-compiler Original workspace: dumb:/java/east/u2/ap31282/hs-g1-fixes-compiler Submitter: ap31282 Archived data: /net/prt-data.east/archives/main/g1_gc_baseline/2007/20070628083005.ap3128 2.hs-g1-fixes-compiler/ Webrev: http://analemma.sfbay.sun.com/net/prt-data.east/archives/main/g1_gc_baseli ne/2007/20070628083005.ap31282.hs-g1-fixes-compiler/workspace/webrevs/webrev-2007.06.28/index.html Fixed 6564247: assert(bb->_end_bci + bc_len == bb[1]._bci,"unmatched bci info in basic block") fai ls Clear the _bb_hdr_bits were not cleared when relocated. Reviewed by: Tom, Andrey Fix verified (y/n): y Verification testing: dacapo eclipse (the failing test) Other testing: several PRT submissions. END COMMENT update: src/share/vm/oops/generateOopMap.cpp Examined files: 4007 Contents Summary: 1 update 4006 no action (unchanged)
05-10-2007

SUGGESTED FIX Chuck, thanks for the fix. It seems to have eliminated the assertion failure, but the run failed further down (after a Full GC). I'll see whether the new failure is related or not.
08-06-2007

SUGGESTED FIX In generateOopMap.cpp, clear the_bb_hdr_bits in update_basic_blocks() when they are re-allocated. Move up the verifier check in init_basic_blocks(). *** /tmp/geta2610 Mon Jun 4 15:13:18 2007 --- generateOopMap.cpp Mon Jun 4 15:11:20 2007 *************** *** 923,928 **** --- 923,939 ---- _basic_blocks[bbNo-1]._end_bci = prev_bci; + // Check that the correct number of basicblocks was found + if (bbNo !=_bb_count) { + if (bbNo < _bb_count) { + verify_error("jump into the middle of instruction?"); + return; + } else { + verify_error("extra basic blocks - should not happen?"); + return; + } + } + _max_monitors = monitor_count; // Now that we have a bound on the depth of the monitor stack, we can *************** *** 956,972 **** } #endif - // Check that the correct number of basicblocks was found - if (bbNo !=_bb_count) { - if (bbNo < _bb_count) { - verify_error("jump into the middle of instruction?"); - return; - } else { - verify_error("extra basic blocks - should not happen?"); - return; - } - } - // Mark all alive blocks mark_reachable_code(); } --- 967,972 ---- *************** *** 999,1004 **** --- 999,1005 ---- BitMap::word_align_up(new_method_size)); _bb_hdr_bits.set_map(new_bb_hdr_bits); _bb_hdr_bits.set_size(new_method_size); + _bb_hdr_bits.clear(); for(int k = 0; k < _bb_count; k++) { if (_basic_blocks[k]._bci > bci) { *** (#1 of 1): [ UNSAVED ] ###@###.###
04-06-2007

EVALUATION It seems that the _bb_hdr_bits are not being cleared when re-allocated.
04-06-2007