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
Posted Date : 2008-12-17 15:17:45.0

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
Posted Date : 2008-12-17 15:17:45.0

<deleted addition to wrong bug>
Posted Date : 2008-12-18 15:23:00.0

N/A

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)

{  xxxxx@xxxxx  }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.
Posted Date : 2008-12-19 23:52:57.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9e5a6ed08fc9
Posted Date : 2009-02-18 06:15:20.0

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9e5a6ed08fc9
Posted Date : 2009-02-21 02:32:50.0