The Hotspot Error comes when the debugger runs
in Windows(Especially in 2000) in JDK1.3-R build.

#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# Error ID: 4F533F57494E13120E43505002BE
#

The error is inconsistent.

This error occurs in 3 different applications among which one is
Swing Testsuite in all windows platforms.

The error occurs in JDK1.3-R build and not in the previous build
(JDK1.3-P)

The bug can be reproduced using the files in the following location
"/net/sqesvr/export/disk5/toolsbugs/4302309"
* Follow the instructions in README to reproduce the bug.

Note:
-----
  The error is again inconsistant, it happens in MKS Tool Kit (KornShell)
  some times and in DOS prompt some times.
* I had run the command  16 times( nmake run) in the MS DOS prompt.
  ( Unjar the attached 130R_result.jar file , you can see all the log files)
* The error, "# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION"
  occured only  3 times.
* Open the following log files, 
          dos_jbug_130r.log1
          dos_jbug_130r.log9
          dos_jbug_130r.log13 and see the error.

--------THE RESULT (dos_jbug_130r.log1)
	java -classpath classes;T:\jdk1.3\win32\lib\tools.jar;T:\jdk1.3\win32\bin\..\jre\lib\rt.jar TestAll
CachingInfo -launch com.sun.jdi.CommandLineLaunch:main=ControlFlow
StackFrameTest -launch com.sun.jdi.CommandLineLaunch:main=FrameTest
public CachingInfo(java.lang.String[])
public StackFrameTest(java.lang.String[])

~~~~ com.sun.jdi.CommandLineLaunch (defaults: home=T:\jdk1.3\win32, options=, main=, suspend=true, quote=", vmexec=java ~~ Connector args: {home=home=T:\jdk1.3\win32, options=options=, main=main=ControlFlow, suspend=suspend=true, quote=quote=", vmexec=vmexec=java}

Launch Target
the connector Args *** {home=home=T:\jdk1.3\win32, options=options=, main=main=ControlFlow, suspend=suspend=true, quote=quote=", vmexec=vmexec=java}
%%%%%
%%%%%/
Virtual  xxxxx@xxxxx 
out of if block
Java HotSpot(TM) Client VM warning: Setting of property "java.compiler" is ignored
JVM version:1.3.0
JDI version: 1.3
JVM description: Java Debug Interface (Reference Implementation) version 1.3 
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.0 (Java HotSpot(TM) Client VM, interpreted mode)
Thread 1-> Finalizer
Thread 2-> Reference Handler
Thread 3-> main
### Cannot get CurrentContendedMonitor for the target VM.
@@@@@@@@@  Thread Referenceinstance of java.lang.Thread(name='main', id=1) calls the method frames(). The time taken is shown below.
Time Taken in MilliSeconds: 10
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
@@@@@@@@@  ThreadGroupReference.threads() calls the method threads(). The time taken is shown below.
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
Time Taken in MilliSeconds: 0
@@@@@@@@@  ObjectReference instance of java.lang.Thread(name='main', id=1) calls the method allThreads(). The time taken is shown below.
### Cannot get CurrentContendedMonitor for the target VM.
Caching info done. You got to check the output PASSED
if, no else
if branch
else branch
caught exception
finally
synchronized
Loop iteration: 1/22
Loop iteration: 2/22
Loop iteration: 3/22
Loop iteration: 4/22
Loop iteration: 5/22
Loop iteration: 6/22
Loop iteration: 7/22
Loop iteration: 8/22
Loop iteration: 9/22
Loop iteration: 10/22
Loop iteration: 11/22
Loop iteration: 12/22
Loop iteration: 13/22
Loop iteration: 14/22
Loop iteration: 15/22
Loop iteration: 16/22
Loop iteration: 17/22
Loop iteration: 18/22
Loop iteration: 19/22
Loop iteration: 20/22
Loop iteration: 21/22
VMDisconnected!


~~~~ com.sun.jdi.CommandLineLaunch (defaults: home=T:\jdk1.3\win32, options=, main=, suspend=true, quote=", vmexec=java ~~ Connector args: {home=home=T:\jdk1.3\win32, options=options=, main=main=FrameTest, suspend=suspend=true, quote=quote=", vmexec=vmexec=java}

Launch Target
the connector Args *** {home=home=T:\jdk1.3\win32, options=options=, main=main=FrameTest, suspend=suspend=true, quote=quote=", vmexec=vmexec=java}
%%%%%
#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# Error ID: 4F533F57494E13120E43505002BE
#


-------------------------------------------------------------------
This error also occurs with                                                    
java version "1.3.0"                                                            
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)                
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

I had run "make run" more then 40 times to reproduce this bug,
it occured only  2 times.

To reproduce the bug go to /net/sqesvr/export/vsn/GammaBase/Bugs/4302309
and run script Doit.ksh on win32 platform.

The file /net/sqesvr/export/vsn/GammaBase/Bugs/4302309/error_win32.log 
contains log messages on winNT.

 xxxxx@xxxxx  2000-09-12

N/A

I'm unable to reproduce this bug, because the instructions to reproduce 
it fail early on.  When I get to 

4. In <WORKSPACE>\test\build\win32 give gnumake.

I get 

$ nmake       JDICLASSES="D:\pbk\GammaBuild\1.3\kestrel_bugs\compiler1\deployed\lib\tools.jar"       BINDIR="D:\pbk\GammaBuild\1.3\kestrel_bugs\compiler1\deployed\bin"
	D:\pbk\GammaBuild\1.3\kestrel_bugs\compiler1\deployed\bin\javac  -classpath classes;D:\pbk\GammaBuild\1.3\kestrel_bugs\compiler1\deployed\lib\tools.jar  -d classes  -g -sourcepath ..\..\src\share\classes ..\..\src\share\classes/jdi/func/*.java  ..\..\src\share\classes/jdi/func/program/*.java  ..\..\src\share\classes\jdi\tests\*.java  ..\..\src\share\classes\jdi\tests\*.java  ..\..\src\share\classes\jdi\tests\program\*.java  ..\..\src\share\classes\jdi\util\*.java  ..\..\src\share\classes\test\extensions\*.java  ..\..\src\share\classes\test\framework\*.java  ..\..\src\share\classes\test\textui\*.java  ..\..\src\share\classes\test\ui\*.java
error: cannot read: ..\..\src\share\classes\jdi\tests\VMLauncher.java
..\..\src\share\classes\jdi\tests\AbstractJDITest.java:21: duplicate class: jdi.tests.AbstractJDITest
public abstract class AbstractJDITest extends TestCase implements jdi.util.EventListener {
                ^
..\..\src\share\classes\jdi\tests\AccessibleTest.java:10: duplicate class: jdi.tests.AccessibleTest

So it looks like I'm missing a file and then there are some other problems.
Needless to say, things go from bad to worse after that.

If someone would fix the directory /net/sqesvr/export/disk5/latestjbug, 
I'd be happy to look at it some more.

That said, the error quoted is the generic "segmentation fault" that's caught by 
the HotSpot JVM but which turned out not to be a NullPointerException in Java 
code.  So it's a segfault in some native code.  It could be in the native code 
for the JVM, but it's at least as likely to be in native code loaded by the 
test itself.  We'll know as soon as we can reproduce the failure.

 xxxxx@xxxxx  2000-01-05

I still can't get this bug to run correctly (or incorrectly :-). 
I unjar'ed the makefile and edited it to point to /usr/local/java/jdk1.3/win32 
did the requested "nmake" and "nmake run".  The test just hangs.  I 
waited several minutes, but nothing seems to be going on.  

Here's my log:

Y:\Bugs\4302309\bug309>nmake

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

        J:\jdk1.3\win32\bin\javac  -classpath classes;J:\jdk1.3\win32\lib\tools.
jar;J:\jdk1.3\win32\bin\..\jre\lib\rt.jar  -d classes  -g Y:\Bugs\4302309\bug309
\*.java

Y:\Bugs\4302309\bug309>nmake run

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

        J:\jdk1.3\win32\bin\java -classpath classes;J:\jdk1.3\win32\lib\tools.ja
r;J:\jdk1.3\win32\bin\..\jre\lib\rt.jar TestAll
CachingInfo -launch com.sun.jdi.CommandLineLaunch:main=ControlFlow
StackFrameTest -launch com.sun.jdi.CommandLineLaunch:main=FrameTest
public CachingInfo(java.lang.String[])
public StackFrameTest(java.lang.String[])


~~~~ com.sun.jdi.CommandLineLaunch (defaults: home=J:\jdk1.3\win32, options=, ma
in=, suspend=true, quote=", vmexec=java ~~ Connector args: {home=home=J:\jdk1.3win32, options=options=, main=main=ControlFlow, suspend=suspend=true, quote=quot
e=", vmexec=vmexec=java}

Launch Target
the connector Args *** {home=home=J:\jdk1.3\win32, options=options=, main=main=C
ontrolFlow, suspend=suspend=true, quote=quote=", vmexec=vmexec=java}
%%%%%
%%%%%/
Virtual  xxxxx@xxxxx 
out of if block
Java HotSpot(TM) Client VM warning: Setting of property "java.compiler" is ignor
ed
JVM version:1.3.0
JDI version: 1.3
JVM description: Java Debug Interface (Reference Implementation) version 1.3
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.0 (Java HotSpot(TM) Client VM, interpreted mode)
Thread 1-> Finalizer
Thread 2-> Reference Handler
Thread 3-> main

What am I doing wrong?  Since you said it was intermittent, I tried it 
10 times with the same result: hang after the 3 thread prints.

Could you try it pointing JDICLASSES at lib\tools.jar and BINDIR at 
bin in the released JDK-1.3.0-R from /usr/local/java?  Is is some 
machine-specific setting?  I have few or none of those. 

 xxxxx@xxxxx  2000-01-10

As suspected, this is a seg fault in native code, not in HotSpot.  
Here's the stack trace at the point of the fault:

DT_SHMEM! 502c2349()
DT_SHMEM! 502c2528()
DT_SHMEM! 502c129f()
0090b294()
00908dbe()
00908ed6()
00908e86()
JVM! unsigned char *  StubRoutines::_code1 + 258 bytes
JavaCalls::call_helper(JavaValue * 0x0000000a, methodHandle * 0x00000000, JavaCallArguments * 0x0e7cfebc, Thread * 0x007722bc) line 341 + 49 bytes
os::os_exception_wrapper(void (JavaValue *, methodHandle *, JavaCallArguments *, Thread *)* 0x0806e840 JavaCalls::call_helper(JavaValue *, methodHandle *, JavaCallArguments *, Thread *), JavaValue * 0x0e7cff1c, methodHandle * 0x0e7cfe6c, JavaCallArguments * 0x0e7cfebc, Thread * 0x00775300) line 814 + 19 bytes
JavaCalls::call(JavaValue * 0x0e7cff1c, methodHandle {...}, JavaCallArguments * 0x0e7cfebc, Thread * 0x00775300) line 266 + 30 bytes
JavaCalls::call_virtual(JavaValue * 0x0e7cff1c, KlassHandle {...}, symbolHandle {...}, symbolHandle {...}, JavaCallArguments * 0x0e7cfebc, Thread * 0x00775300) line 162 + 18 bytes
JavaCalls::call_virtual(JavaValue * 0x0e7cff1c, Handle {...}, KlassHandle {...}, symbolHandle {...}, symbolHandle {...}, Thread * 0x00775300) line 169
thread_entry(JavaThread * 0x00775300, Thread * 0x00775300) line 1632 + 44 bytes
JavaThread::thread_main_inner(JavaThread * 0x00775300) line 701 + 5 bytes
JavaThread::thread_main(JavaThread * 0x00775300) line 688 + 9 bytes
_start(void * 0x00772770) line 208 + 14 bytes
MSVCRT! 7800265a()
KERNEL32! 77f04ee8()

which puts it firmly in the DT_SHMEM code, for which I don't have the 
symbols.  I can see that this is a new Java thread being started up, 
and this is the first call inside that thread.  The Java stack trace 
looks like: 

 for thread: "JDI Target VM Interface" prio=5 tid=0x775300 nid=0x163 runnable [0
xe7cf000..0xe7cfdbc]

 1 - com.sun.tools.jdi.SharedMemoryConnection.receivePacket0(Native Method)
 2 - com.sun.tools.jdi.SharedMemoryConnection.receivePacket(SharedMemoryConnection.java:61)
 3 - com.sun.tools.jdi.TargetVM.run(TargetVM.java:97)
 4 - java.lang.Thread.run(Thread.java:484)

which looks right, and shows the Java code diving into the shared memory code. 
In case it will help, here's the assembler code for the method around the faulting 
instruction:

502C233E   push        esi
502C233F   mov         esi,dword ptr [esp+0Ch]
502C2343   push        edi
502C2344   xor         edi,edi
502C2346   mov         eax,dword ptr [esi+0Ch]
502C2349   mov         ecx,dword ptr [eax+0E8h]    <!-- faults here: eax contains 0E741478 -->
502C234F   cmp         ecx,dword ptr [eax+0E4h]
502C2355   jne         502C238F
502C2357   cmp         byte ptr [eax+0ECh],0
502C235E   jne         502C238F
502C2360   test        edi,edi
502C2362   jne         502C238F
502C2364   push        esi
502C2365   call        502C2267
502C236A   test        eax,eax
502C236C   pop         ecx
502C236D   jne         502C2391
502C236F   push        dword ptr [esi+4]
502C2372   mov         eax,dword ptr [esp+10h]
502C2376   push        dword ptr [eax+74h]
502C2379   call        502C2872
502C237E   push        esi
502C237F   mov         edi,eax
502C2381   call        502C225A
502C2386   add         esp,0Ch
502C2389   test        eax,eax
502C238B   je          502C2346
502C238D   jmp         502C2391
502C238F   mov         eax,edi
502C2391   pop         edi
502C2392   pop         esi
502C2393   ret

Since this happens only intermittently it's liable to be a synchronization problem: 
this thread reading some value that's not quite synchronized with the writer of the 
field.  But that could be a read herring.  This looks like the very first call on the 
thread to me, but of course all calls to Thread.run look like the first calls to the 
JVM: there's probably a loop in there so this thread could have been running for a 
long time.

The bug probably show up more under HotSpot because the timing of things under HotSpot 
is different than under classic.  The bug traps to HotSpot as a EXCEPTION_ACCESS_VIOLATION 
because HotSpot has a seg fault handler that catches seg faults as a way of implicitly 
catching NullPointerExceptions.  The problem (for HotSpot developers) is that it catches 
all seg faults in native code, too, so people blame us for all these errors.

I'm reassigning this bug to Andrew so someone can look at the DT_SHMEM code.  
I had to run it several times to get it to fail (1 in 8?).  If it's really a 
timing problem, then diagnostic tracing may make it impossible to reproduce.  

As a reminder to me, I ran with ShowMessageBoxOnError=true so I could grab the 
debuggee when it failed.

 xxxxx@xxxxx  2000-01-10

I run into the same hangs that Peter describes above. Please give us a test case that is reproducible.
 xxxxx@xxxxx  2000-02-18

Unable to get reproducible test case from submitter.  Closing this bug
report as not reproducible.

 xxxxx@xxxxx  2000-12-22

SHMEM hangs when running the debugger in JBuilder on win2k, 
the type of errors are produced, and it is VERY 
reproducable (causes JBuilder to hang, most annoying!!)

j2sdk1.4.2_03