JDK-4509816 : RAS: Vtest, Vmark client intermittent Fail in merlin_b81 c2 on win2ksp1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0,1.4.0_01
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt,windows_2000
  • CPU: x86
  • Submitted: 2001-10-02
  • Updated: 2002-09-13
  • Resolved: 2002-09-13
Related Reports
Duplicate :  
JDK-4742833 - RetData::fixup_ret keeps oop live across RetData_lock which may GC
Duplicate :  
JDK-4729122 - JVM fails with Access Violation in -server mode gives hotspot error
Relates :  
JDK-4765517 - Intermittant SEGV in methodDataOopDesc:data_before
Description
RAS: Vtest, Vmark client intermittent Fail in merlin_b81 c2 on win2ksp1

JDK version
=============
java version "1.4.0-beta3" (run on 2k)
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b81)
Java HotSpot(TM) Server VM (build 1.4.0-beta3-b81, mixed mode)

Platform
=============
Windows_NT JTG-WIN5 5 00 586 (run c2)

Error message
=============
**VTest client intermitten error 
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6D5912AA 
Function=JVM_RegisterUnsafeMethods+0x1984A 
Library=c:\jdk1.3\jre\bin\server\jvm.dll 

Current Java thread: 
        at COM.volano.mbz.q(Unknown Source) 
        at COM.volano.mbw.update(Unknown Source) 
        at java.util.Observable.notifyObservers(Observable.java:145) 
        at COM.volano.mby.����(Unknown Source) 
        at COM.volano.mby.run(Unknown Source) 
        at java.lang.Thread.run(Thread.java:539) 
Local Time = Sun Sep 30 07:03:31 2001 
Elapsed Time = 5 
# 
# HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION 
# Error ID : 4F530E43505002BA 
# Please report this error at 
# http://java.sun.com/cgi-bin/bugreport.cgi 
# 
# Java VM: Java HotSpot(TM) Server VM (1.4.0-beta3-b81 mixed mode) 
# 
==================================================
**Vmark client intermitten error 
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6D5912AA 
Function=JVM_RegisterUnsafeMethods+0x1984A 
Library=c:\jdk1.3\jre\bin\server\jvm.dll 

Current Java thread: 
        at java.util.Observable.clearChanged(Observable.java:174) 
        at java.util.Observable.notifyObservers(Observable.java:141) 
        - locked <02FEB548> (a COM.volano.mby) 
        at COM.volano.mby.����(Unknown Source) 
        at COM.volano.mby.run(Unknown Source) 
        at java.lang.Thread.run(Thread.java:539) 
Local Time = Thu Sep 14 17:18:26 2000 
Elapsed Time = 3 
# 
# HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION 
# Error ID : 4F530E43505002BA 
# Please report this error at 
# http://java.sun.com/cgi-bin/bugreport.cgi 
# 
# Java VM: Java HotSpot(TM) Server VM (1.4.0-beta3-b81 mixed mode) 
# 

Notes
=============
please check http://jtgb4u4c.eng/bigapps for test results tables

Testing results are backupped in 
jtg-win1 that can be accessed by telnet (root/admin as id/passwd) or http://jtg-win1
  
How to reproduce bug:
telnet to the hosts shown in web for linux test machine with root/admin as id/passwd
goto z:/1.3NTscripts to execute script and d:/tmp to get the running results

for example: (refer the webpage for exact host)
telnet to jtg-win1 with root/admin as id/passwd
execute sh z:/1.3NTscripts/runxxxxx.ksh stab -server (give the "stab" as 1st para)
cd to d/tmp/runxxx.xxx-server to get the results
###@###.### 2001-10-02
Comments
EVALUATION ?????? Look at Error message .. How can the Library be a 1.3 base and the server VM be a 1.4 base. The crash/output does not seem to be consistent. ###@###.### 2001-10-02 I ran with John Rose's fix to 4506997 but it gets EXCEPTION_ACCESS_VIOLATION with the stack trace below on 2x processor 900 mhz NT after ~5 hours. Never seen this before. NTDLL! 77f67ef7() USER32! 77e999bd() USER32! 77e8bbf6() USER32! 77e8bb6d() USER32! 77e8b6bd() JVM! os::message_box(char const *,char const *) + 23 bytes JVM! os::handle_unexpected_exception(class Thread *,int,unsigned char *,void *) + 141 bytes JVM! topLevelExceptionFilter(struct _EXCEPTION_POINTERS *) + 323 bytes JVM! os::os_exception_wrapper(void (*)(class JavaValue *,class methodHandle *,cl ass JavaCallArguments *,class Thread *),class JavaValue *,class methodHandle *,c lass JavaCallArguments *,class Thread *) + 78 bytes JVM! JavaCalls::call(class JavaValue *,class methodHandle,class JavaCallArgument s *,class Thread *) + 30 bytes JVM! SystemDictionary::define_instance_class(class instanceKlassHandle,class Thr ead *) + 419 bytes JVM! SystemDictionary::resolve_from_stream(class symbolHandle,class Handle,class Handle,class ClassFileStream *,class Thread *) + 224 bytes JVM! JVM_DefineClass@24 + 246 bytes JVM! Unsafe_DefineClass0(struct JNIEnv_ *,class _jobject *,class _jstring *,clas s _jbyteArray *,int,int) + 1083 bytes JVM! Unsafe_DefineClass1(struct JNIEnv_ *,class _jobject *,class _jstring *,clas s _jbyteArray *,int,int,class _jobject *,class _jobject *) + 155 bytes 00ab93c7() ###@###.### 2001-10-03 Oh, stack dump may be bogus, because it's getting an exception while it was handling another exception, it says in the log file. The other error points to compute_and_set_is_subtype_of(). Another exception has been detected while we were handling last error. Dumping information about last error: ERROR REPORT FILE = (N/A) PC = 0x080E2F5B SIGNAL = -1073741819 FUNCTION NAME = (N/A) OFFSET = 0xFFFFFFFF LIBRARY NAME = (N/A) Please check ERROR REPORT FILE for further information, if there is any. Good bye. % ###@###.### 2001-10-03 I've reproduced this as an error in methodDataOop, some bits of mail attached. > It says it's in methodDataOopDesc::bci_to_dp, I added a guarantee that it > didn't hit. It dies on line 4 in the call to data_before(bci). > > 1address methodDataOopDesc::bci_to_dp(int bci) { > 2 ResourceMark rm; > 3 guarantee(this != NULL && this->_data != NULL && this->is_oop(), "naked oop > used?"); > 4 ProfileData* data = data_before(bci); > 5 ProfileData* prev = NULL; > 6 for ( ; is_valid(data); data = next_data(data)) { > 7 if (data->bci() >= bci) { > 8 if (data->bci() == bci) set_hint_di(dp_to_di(data->dp())); > 9 else if (prev != NULL) set_hint_di(dp_to_di(prev->dp())); > 10 return data->dp(); > 11 } > 12 prev = data; > 13 } > 14 return (address)limit_data_position(); > 15} > > Since data_before is inlined in the header file, I put the implementation > in the .cpp file so I could see which line it faults on which is line 7 > (doesn't trigger guarantee here either!!): > > #if 1 > 1 ProfileData* methodDataOopDesc::data_before(int bci) { > 2 int hint = hint_di(); > 3 if (data_layout_at(hint) == NULL) { > 4 tty->print_cr("hint_di %d bci %d _data %p this %p", _hint_di, bci, _data, > this); > 5 guarantee(data_layout_at(hint) != NULL, "data layout bad"); > 6 } > 7 if (data_layout_at(hint)->bci() <= bci) > 8 return data_at(hint); > 9 else > 10 return first_data(); > 11 } > #endif > > Since this fault is during a java call, on windows we have a SEH structured > exception handler that unwinds the stack, so there's no stack trace. I > don't know what called bci_to_dp. When I inlined bci_to_dp, the timing > changed such that it didn't fail. Hence, the latest evaluation of this bug is an infrequently occurring race condition in methodDataOop stuff. I can reproduce this on a 4x w2k system. I also believe the bug in 4650888 occurs more frequently than this bug and is hiding this bug. ###@###.### 2002-06-03 This bug was sighted before and in hopper b06 but is gone in b08 and later. It may have been fixed as a side effect of another bug fix or other work. Since it was found by another customer, and definitely exists in merlin, it would be good to find out what fixed it and close it as FIX. ###@###.### 2002-09-04 Given the low freq when it was around, we've (Mike P & I) have decided to take your earlier advice and CNR it. :-) If it comes around again, we'll look at it then. Seperately, via inspection I've got my hands on a crushed EBX bug with MDO's and the _ret bytecode. ###@###.### 2002-09-04
04-09-2002