In the nightlies of 2012-01-20 there are a lot of similar failures. Several different test cases fail with the same stacktrace. Here is the top of a typical hs_err file:

;; Using jvm: "/export/local/common/jdk/baseline/solaris-sparcv9/jre/lib/sparcv9/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/170217.brutisso/source/src/share/vm/oops/oop.inline.hpp:484), pid=23441, tid=35
#  assert((s == klass->oop_size(this)) || (Universe::heap()->is_gc_active() && ((is_typeArray() && UseParNewGC) || (is_objArray() && is_forwarded() && (UseParNewGC || UseParallelGC || UseG1GC))))) failed: wrong array object size
#
# JRE version: 7.0_04-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b10-internal-201201201702.brutisso.hs-gc-hum-alloc-fa-fastdebug mixed mode solaris-sparc compressed oops)
# Core dump written. Default location: /export/local/57664.JDK7.NIGHTLY.VM_solaris-sparcv9_vm_server_mixed_vm.gc.testlist/results/ResultDir/Juggle03/core or core.23441
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x000000010ade8000):  ConcurrentGCThread [stack: 0x0000000000000000,0x0000000000000000] [id=35]

Stack: 
[error occurred during error reporting (printing stack bounds), id 0xe0000000]

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12eee94]  void VMError::report_and_die()+0x794;;  void VMError::report_and_die()+0x794
V  [libjvm.so+0x763608]  void report_vm_error(const char*,int,const char*,const char*)+0x78;;  void report_vm_error(const char*,int,const char*,const char*)+0x78
V  [libjvm.so+0x12edb38]  void VMError::report(outputStream*)+0x9a8;;  void VMError::report(outputStream*)+0x9a8
V  [libjvm.so+0x12eee94]  void VMError::report_and_die()+0x794;;  void VMError::report_and_die()+0x794
V  [libjvm.so+0x763608]  void report_vm_error(const char*,int,const char*,const char*)+0x78;;  void report_vm_error(const char*,int,const char*,const char*)+0x78
V  [libjvm.so+0x6d903c]  void CMTask::scan_object(oop)+0x864;;  void CMTask::scan_object(oop)+0x864
V  [libjvm.so+0x6e12c4]  bool CMBitMapClosure::do_bit(unsigned long)+0x23c;;  bool CMBitMapClosure::do_bit(unsigned long)+0x23c
V  [libjvm.so+0x6dd290]  bool CMBitMapRO::iterate(BitMapClosure*,MemRegion)+0x100;;  bool CMBitMapRO::iterate(BitMapClosure*,MemRegion)+0x100
V  [libjvm.so+0x6db474]  void CMTask::do_marking_step(double,bool,bool)+0x43c;;  void CMTask::do_marking_step(double,bool,bool)+0x43c
V  [libjvm.so+0x6dfe44]  void CMConcurrentMarkingTask::work(unsigned)+0x1ec;;  void CMConcurrentMarkingTask::work(unsigned)+0x1ec
V  [libjvm.so+0x132b028]  void GangWorker::loop()+0x2a0;;  void GangWorker::loop()+0x2a0
V  [libjvm.so+0xf9a8f8]  java_start+0x270;;  java_start+0x270

Full file available here:
http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2012-01-20/G1_GC_Baseline/vm/solaris-sparcv9/server/mixed/solaris-sparcv9_vm_server_mixed_vm.gc.testlist/ResultDir/Juggle03/hs_err_pid23441.log

This is most likely related to these two changes:

changeset:   2981:57025542827f
user:        brutisso
date:        Fri Jan 20 18:01:32 2012 +0100
summary:     7131791: G1: Asserts in nightly testing due to 6976060

changeset:   2977:9509c20bba28
user:        brutisso
date:        Mon Jan 16 22:10:05 2012 +0100
summary:     6976060: G1: humongous object allocations should initiate marking cycles when necessary

Change 2977 introduced several issues. Change 2981 removed them, but introduced the issue above.

A theory of what i happening is that with change 2981 we temporarily set up a piece of memory to look like an int array that has the right size to cover the object we would like to put in this memory. We then might trigger a collection and start a marking cycle. If the concurrent marking thread find the fake int array at the same time as we updated it with the actual object information we can get into trouble.

The most common failure is the assert above. In the nightlies there are also two failures that hit a guarantee instead. I think this has the same cause as the assert.

The guarnatee failures look like:

guarantee(!failures) failed: there should not have been any failures

Here are the hs_err files for those two failures:
http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2012-01-20/G1_GC_Baseline/vm/solaris-sparcv9/server/mixed/solaris-sparcv9_vm_server_mixed_vm.gc.testlist/ResultDir/Compact_Strings_TwoFields/hs_err_pid28580.log
http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2012-01-20/G1_GC_Baseline/vm/windows-amd64/server/mixed/windows-amd64_vm_server_mixed_vm.gc.testlist/ResultDir/Compact_Strings_TwoFields/hs_err_pid5492.log