JDK-6786346 : intermittent Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-12-17
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
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
6u18Fixed 7Fixed hs15Fixed
Description
The following entry was from an older nightly.

New nsk.jvmti failures (from 2008.12.01)
    nsk/jvmti/ResourceExhausted/resexhausted004
        This test failed the following assertion on Linux IA32 Client
        VM (machine sfx2100-05) and Solaris X86 Client VM (machine julius):

            Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226)
            Error: assert((new_end_aligned >= _committed[ri].start()) &&
                (_committed[ri].start() > _committed[ind].start()),
                "New end of committed region is inconsistent")

        This test is covered by the following test bug:

            6601628 4/4 TEST_BUG: Unable to allocate free memory in
                        resexhausted004

        This bug's state was changed to "fix available" on 2008.12.01
        for v160r23, but we're using v160r22.

        Update: Nicolay noticed the bug was marked as fixed in b23 and
            that should have been r23.

        Update: This test is now back on the exclude list.
            I will delete this entry in the next report.


It looks like this failure wasn't related to the test bug.
Here are the URLs:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-12-01/Serv_Baseline/vm/linux-i586/client/comp/linux-i586_client_comp_nsk.jvmti.testlist/analysis.html
http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-12-01/Serv_Baseline/vm/solaris-i586/client/comp/solaris-i586_client_comp_nsk.jvmti.testlist/analysis.html
New nsk.jvmti failures (from 2008.12.16)
*   nsk/jvmti/ResourceExhausted/resexhausted002
        This test failed the following assertion on Solaris SPARC
        Server VM (machine naboovm):

            Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226)
            Error: assert((new_end_aligned >= _committed[ri].start()) &&
                (_committed[ri].start() > _committed[ind].start()),
                "New end of committed region is inconsistent")

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-12-16/Serv_Baseline/vm/solaris-sparc/server/comp/solaris-sparc_server_comp_nsk.jvmti.testlist/analysis.html
<deleted addition to wrong bug>
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9e5a6ed08fc9
21-02-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9e5a6ed08fc9
18-02-2009
EVALUATION I failed to reproduce it on some of the machines I usually use (dumber.east, maple.east, I did over 100 iterations). However, it reproduces every time on the testing box (naboovm.sfbay) {ap31282@naboovm}136: whatami DATE: Fri Dec 19 15:52:13 PST 2008 USER: ap31282 HOSTNAME: hme0 = naboovm IP ADDRESS: hme0 = 10.5.20.213 MODEL: SUNW,Ultra-4 CPU: SUNW,UltraSPARC-II CPU: SUNW,UltraSPARC-II CPU: SUNW,UltraSPARC-II CPU: SUNW,UltraSPARC-II FRAME BUFFER(S): unknown SunOS RELEASE: 5.10 TYPE: homeless FILESERVER: ubur-home1.east MEMORY: 1024MB SWAP: 2638.8MB total, 981.0MB used, 1657.8MB available LOAD AVERAGE: 1.30, 1.32, 1.30 SOFTWARE SERVER(S): mf-sfbay-04,mf-sfbay-03,mf-sfbay-02 DEFAULT PRINTER: ubur02p20sgl ETHERNET ADDRESS: 8:0:20:b6:6e:d3 HOSTID: 80b66ed3 with the latest (as of today, Dec 19, 2008) hotspot-gc. I can reproduce it with debug and fastdebug JVMs, but not with the product JVM (the run would successfully complete). Unfortunately, for some reason, dbx refused to connect to the debug JVM so I couldn't get any more info. I attached the rerun.sh file from the testing page for your convenience.
19-12-2008