Here is an entry from my nightly analysis report:

New INSTRUMENT_REGRESSION failures (from 2008.05.09)
    java/lang/instrument/PremainClass/InheritAgent0111.java
        This test failed the following assertion:

            Internal Error (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
            Error: assert(method->signature_handler() ==
                Interpreter::slow_signature_handler() || _handlers->find(
                method->signature_handler()) == _fingerprints->find(
                Fingerprinter(method).fingerprint()),"sanity check")

        on Linux IA32 Server VM (machine opteron001).

I have only seen this failure once so this is a simple bug sighting
and not a readily reproducible failure.


Here is a snippet from the test's .jtr file:

----------System.out:(20/1263)----------
TESTSRC=/export/local/common/testbase/jtreg/INSTRUMENT_REGRESSION/test/java/lang/instrument/PremainClass
TESTJAVA=/export/local/common/jdk/baseline/linux-i586
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/interpreterRuntime.cpp:1106
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/tmp/jprt-jprtadm/temp/P1/B/163014.dcubed/source/src/share/vm/interpreter/interpreterRuntime.cpp:1106), pid=26700, tid=1471642544
# Error: assert(method->signature_handler() == Interpreter::slow_signature_handler() || _handlers->find(method->signature_handler()) == _fingerprints->find(Fingerprinter(method).fingerprint()),"sanity check")
#
# Java VM: OpenJDK Client VM (12.0-b03-2008-05-09-163014.dcubed.hotspot-hg-6670684-merge-hsx-13-fastdebug mixed mode, sharing linux-x86)
# An error report file with more information is saved as:
# /export/local/5581.JDK7.NIGHTLY.VM+linux-i586_server_comp_INSTRUMENT_REGRESSION/results/java/lang/instrument/PremainClass/InheritAgent0111/hs_err_pid26700.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 1471642544
Dumping core ...
added manifest
----------System.err:(2/227)----------
/export/local/common/testbase/jtreg/INSTRUMENT_REGRESSION/test/java/lang/instrument/PremainClass/../MakeJAR3.sh: line 52: 26700 Aborted ${JAVAC} ${AGENT}.java
InheritAgent0111*.class : no such file or directory
result: Failed. Execution failed: exit code 1


test result: Failed. Execution failed: exit code 1



Here is a snippet from the hs_err log file:

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

Current thread (0x080a3c00): JavaThread "Reference Handler" daemon [_thread_in_vm, id=26703, stack(0x57b27000,0x57b78000)]

Stack: [0x57b27000,0x57b78000], sp=0x57b76ae4, free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x779f63];; _ZN7VMError14report_and_dieEv+0x273
V [libjvm.so+0x3b33b5];; _Z24report_assertion_failurePKciS0_+0x55
V [libjvm.so+0x43dea6];; _ZN23SignatureHandlerLibrary3addE12methodHandle+0x196
V [libjvm.so+0x43ea73];; _ZN18InterpreterRuntime19prepare_native_callEP10JavaThreadP13methodOopDesc+0x163
j java.lang.Object.wait(J)V+0
j java.lang.Object.wait()V+2
j java.lang.ref.Reference$ReferenceHandler.run()V+46
v ~StubRoutines::call_stub
V [libjvm.so+0x4445a0];; _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x260
V [libjvm.so+0x64ab28];; _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x18
V [libjvm.so+0x443baf];; _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0xff
V [libjvm.so+0x443d47];; _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x67
V [libjvm.so+0x5095b2];; _Z12thread_entryP10JavaThreadP6Thread+0x82
V [libjvm.so+0x72fafc];; _ZN10JavaThread17thread_main_innerEv+0xcc
V [libjvm.so+0x64c4d8];; _Z10java_startP6Thread+0x138
C [libpthread.so.0+0x5297]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.Object.wait(J)V+0
j java.lang.Object.wait()V+2
j java.lang.ref.Reference$ReferenceHandler.run()V+46
v ~StubRoutines::call_stub


One thing that caught my eye is that this crash is from the Client VM,
but the VM under test is the Server VM. Taking a closer look at the .jtr
file shows:

../MakeJAR3.sh: line 52: 26700 Aborted ${JAVAC} ${AGENT}.java

Here is a snipped from the MakeJAR3.sh script:

    48 JAVAC="${TESTJAVA}/bin/javac -g"
    49 JAR="${TESTJAVA}/bin/jar"
    50
    51 cp ${TESTSRC}/${AGENT}.java .
    52 ${JAVAC} ${AGENT}.java
    53
    54 echo "Manifest-Version: 1.0" > ${AGENT}.mf
    55 echo Premain-Class: ${AGENT} >> ${AGENT}.mf
    56 shift
    57 while [ $# != 0 ] ; do
    58 echo $1 >> ${AGENT}.mf
    59 shift
    60 done
    61
    62
    63 ${JAR} cvfm ${AGENT}.jar ${AGENT}.mf ${AGENT}*.class
Here is a link to the nightly results page:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-05-09/Serv_Baseline/javase/linux-i586/server/comp/javase-linux-i586_server_comp_INSTRUMENT_REGRESSION2008-05-09-20-14-12/analysis_new.html
Another sighting in nightly testing:

New JDI_REGRESSION failures (2009.02.20)
* com/sun/jdi/VarargsTest.java
        This test failed the following assertion on Linux AMD64 Server
        VM -Xcomp (machine bunt):

            Internal Error (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
            Error: assert(method->signature_handler() ==
              Interpreter::slow_signature_handler() || _handlers->find(
              method->signature_handler()) == _fingerprints->find(
              Fingerprinter(method).fingerprint()),"sanity check")

        This is an occurrence of the following bug:
            6704010 4/4 Internal Error (src/share/vm/interpreter/
                        interpreterRuntime.cpp:1106)

        I will add this entry to 6704010.

Update: here are links to the analysis page and the hs_err_pid file:

http://sqeweb.sfbay/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2009-02-20/RT_Baseline/javase/linux-amd64/server/comp/linux-amd64_server_comp_JDI_REGRESSION/analysis.html
http://sqeweb.sfbay/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2009-02-20/RT_Baseline/javase/linux-amd64/server/comp/linux-amd64_server_comp_JDI_REGRESSION/workDir/com/sun/jdi/VarargsTest/hs_err_pid2050.log

According to this snippet in the hs_err_pid file, this is
again javac:

VM Arguments:
jvm_args: -Dapplication.home=/export/local/common/jdk/baseline/linux-amd64 -Xms8m
java_command: com.sun.tools.javac.Main -d /export/local/12220.JDK7.NIGHTLY.VM+linux-amd64_server_comp_JDI_REGRESSION/results/workDir/classes/com/sun/jdi -classpath /export/local/common/jtreg/lib/javatest.jar:/export/local/common/jtreg/lib/jtreg.jar:/export/local/12220.JDK7.NIGHTLY.VM+linux-amd64_server_comp_JDI_REGRESSION/results/workDir/classes/com/sun/jdi:/export/local/common/testbase/jtreg/JDI_REGRESSION/test/com/sun/jdi:/export/local/common/jdk/baseline/linux-amd64/lib/tools.jar -sourcepath /export/local/common/testbase/jtreg/JDI_REGRESSION/test/com/sun/jdi:/export/local/common/jdk/baseline/linux-amd64/lib/tools.jar -g -source 1.5 -target 1.5 /export/local/common/testbase/jtreg/JDI_REGRESSION/test/com/sun/jdi/VarargsTest.java
Launcher Type: SUN_STANDARD
I ran into this failure mode while chasing the following bug:

    6910405 4/4 JDI resume002 test fails intermittently

I was doing a 12 hour doit_loop run trying to determine the
frequency of the 6910405 failure mode and ran into one instance
of this failure mode. The failing test is:

    nsk/jdi/EventSet/resume/resume002

Here is the asserting thread's stack:

THREAD t@7

t@7 (l@7) stopped in __lwp_kill at 0xfeec9315
0xfeec9315: __lwp_kill+0x0015: jae __lwp_kill+0x23 [ 0xfeec9323, .+
0xe ]
current thread: t@7
=>[1] __lwp_kill(0x7, 0x6), at 0xfeec9315
  [2] raise(0x6), at 0xfee71d73
  [3] abort(0xfed7e448, 0xfea44a36, 0x0), at 0xfee51bbd
  [4] os::abort(0x1, 0x816f800, 0x1, 0xfed987c8), at 0xfdcd8be4
  [5] VMError::report_and_die(0xd56af584, 0xfeceb140, 0xd56af5cc, 0xfd1ba229), a
t 0xfe0d9769
  [6] report_assertion_failure(0xfe67735a, 0x4f3, 0xfe677292, 0xfd469919), at 0x
fd1ba249
  [7] SignatureHandlerLibrary::add(0x81701b8, 0x816f800, 0xd56af8f4, 0xfd46aad6)
, at 0xfd46aab8
  [8] InterpreterRuntime::prepare_native_call(0x816f800, 0xd5a05f28), at 0xfd46b
0d2
  [9] 0xf941329d(0x0, 0x0, 0x0, 0x0, 0xf5a00bd0, 0x1), at 0xf941329d
  [10] 0xf940318d(0x0, 0x0, 0xf5a00bd0, 0x0, 0x0, 0xf5a00bb8), at 0xf940318d
  [11] 0xf9403027(0xf5a00bb8, 0xd56afa14, 0xd5aa4ecb, 0xd56afa40, 0xd5aa5190, 0x
0), at 0xf9403027
  [12] 0xf9403027(0x0, 0xf5a00be0, 0x2, 0x1f80, 0xfeceb140, 0x1), at 0xf9403027
  [13] 0xf94003a8(0xd56afaf0, 0xd56afd84, 0xa, 0xd5aa4ee8, 0xf9410f40, 0xd56afc7
8, 0x1, 0x816f800), at 0xf94003a8
  [14] JavaCalls::call_helper(0xd56afd80, 0xd56afbb4, 0xd56afc70, 0x816f800), at
 0xfd4784af
  [15] os::os_exception_wrapper(0xfd477ca4, 0xd56afd80, 0xd56afbb4, 0xd56afc70,
0x816f800, 0x81701a0, 0x81701a8, 0xfd477c3c), at 0xfdcdea87
  [16] JavaCalls::call(0xd56afd80, 0x81701b0, 0xd56afc70, 0x816f800), at 0xfd477
c74
  [17] JavaCalls::call_virtual(0xd56afd80, 0x81701a4, 0xfeda0070, 0xfeda0338, 0x
d56afc70, 0x816f800, 0x0, 0xfd4771c0, 0x0, 0x0, 0x0, 0x81701a0, 0xfed20168, 0xfe
ceb140, 0xf5a00be0, 0xfd352b13, 0x8084ad0, 0xd5a00000, 0x0, 0xfd352962), at 0xfd
4770b0
  [18] JavaCalls::call_virtual(0xd56afd80, 0x81701a0, 0x81701a4, 0xfeda0070, 0xf
eda0338, 0x816f800, 0xd56afd50, 0xfd5fbfbe), at 0xfd47726d
  [19] thread_entry(0x816f800), at 0xfd5fc22d
  [20] JavaThread::thread_main_inner(0x816f800, 0xab, 0x3ec, 0xfdfe56fe), at 0xf
dfe5d73
  [21] JavaThread::run(0x816f800, 0xfeceb140, 0xd56affd8, 0xfdcd6acc), at 0xfdfe
5a6d
  [22] java_start(0x816f800), at 0xfdcd6b93
  [23] _thr_setup(0xfc702a00), at 0xfeec59b9
  [24] _lwp_start(), at 0xfeec5ca0

I've attached the complete threads.log file and the hs_err file.