Bug ID: JDK-4426365 RAS: VTEST failed imtermittenly on Solaris x86 with Merlin b55 -client

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 1.4.0

Priority: P1
Status: Closed
Resolution: Duplicate
OS: solaris
CPU: x86

Submitted: 2001-03-15
Updated: 2001-04-17
Resolved: 2001-04-17

Machine: jtgbp62a (Solaris 2.6,  x86)
With Merlin b55 -client, VolanoTest failed intermittenly ( 105/1000)
Error message:
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002D6
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4beta-B55 mixed mode)

How to reproduce the problem:
1. telnet jtgbp62a  password for root is jtgbp62a
2. /bs/runvtest.ksh -client
3. cd /bt/VolanoTest*
4. check run.vtest.out 

june.zhong@eng 2001-03-15

EVALUATION Unfortunately this didn't produce any core file (though it seems it should have). Looks like this might be two different failures but until I reproduce it myself under a debugger or SA won't know for sure. steve.goldman@east 2001-03-26 I have a core file for this in /home/coleenp/volano/VolanoTestrun.1486 Looks like the 'src' parameter to Runtime1::arraycopy() is bad from the "where" output: [11] JVM_handle_solaris_signal(0xb, 0xcf76080c, 0xcf76060c, 0x1), at 0xdee1640b [12] signalHandler(), at 0xdee13d4f [13] __sighndlr(0xb, 0xcf76080c, 0xcf76060c, 0xdee13d2c), at 0xdfb778a7 [14] sigacthandler(), at 0xdfb8580f ---- called from signal handler with signal 11 (SIGSEGV) ------ [15] Runtime1::arraycopy(0x2, 0x0, 0xd5058708, 0x3f, 0xd50870f8), at 0xdeed33b7 [16] 0xdb50cbed(), at 0xdb50cbec [17] 0xdb50bba0(), at 0xdb50bb9f [18] 0xdb402db6(), at 0xdb402db5 [19] 0xdb402db6(), at 0xdb402db5 [20] 0xdb402db6(), at 0xdb402db5 [21] 0xdb509351(), at 0xdb509350 [22] 0xdb5049f5(), at 0xdb5049f4 [23] 0xdb4ffa04(), at 0xdb4ffa03 [24] 0xdb50428f(), at 0xdb50428e [25] 0xdb402cd0(), at 0xdb402ccf [26] 0xdb40300c(), at 0xdb40300b [27] 0xdb40016a(0xcf760b58, 0xcf760cd4, 0xa, 0xd901d168, 0xdb407fa0, 0xcf760c68, 0x1, 0x82b3c58), at 0xdb400169 [28] JavaCalls::call_helper(0xcf760cd0, 0xcf760bf8, 0xcf760c60, 0x82b3c58), at 0xded9bfd0 [29] os::os_exception_wrapper(0xded9be80, 0xcf760cd0, 0xcf760bf8, 0xcf760c60, 0x82b3c58), at 0xdee13cc7 [30] JavaCalls::call(0xcf760cd0, 0x82b41a8, 0xcf760c60, 0x82b3c58), at 0xded9b ... I will try to see if I can use CompileOnly to see if it's a compiler1 problem. coleen.phillimore@east 2001-03-26 Also seen as a bad oop during GC. [14] sigacthandler(), at 0xdfb8580f ---- called from signal handler with signal 11 (SIGSEGV) ------ [15] oopDesc::mark(0x10), at 0xded6fa86 [16] ScanClosure::do_oop(0xdd4b0ac0, 0xd14e0930), at 0xded700ce [17] OopMapSet::all_do(0xdd4b0994, 0xdb50b588, 0xdd4b09a0, 0xdd4b0ac0, 0xdee01 Easy to reproduce with -client but ran through the night with -XX:-UseCompilerSafepoints. Also ran with -XX:+SafepointALot (and other stress options like FullGCALot) but that didn't help reproduce it. I wasn't able to reproduce it in <10 iterations with CompileOnly for each volano class individually. We suspect a c1 problem, so this is reassigned there. coleen.phillimore@east 2001-04-03 This may very well be related to the problem being solved by Tom fix for the latest beta (b60???). From Coleens the above description I suspect the bug may not happen with next build. Also, since the test works with -XX:-UseCompilerSafepoints gives a clue. This should be easily reproducible with -XX:+SafepointALot with and interval of 1-10 -XX:GuaranteedSafepointInterval=2 for example. If you see a branch with a safepoint then anything is fair game. Then again I could wrong. mohammad.gharahgouzloo@Eng 2001-04-10 I will mark this bug as a duplicate of 4427606. On x86 platforms this bug would show up sometime as a badoop during GC. please see 4427606 for a small test case that displays the same behavior. mohammad.gharahgouzloo@Eng 2001-04-16

16-04-2001