-
Bug
-
Resolution: Duplicate
-
P1
-
None
-
1.1.4
-
x86
-
windows_nt
This bug appears to have just started occuring in 1.1.3:
From: "Schiller,Thorsten" <###@###.###>
To: "'wyant'" <###@###.###>
Subject: JDK 1.1.3 Bug
Date: Wed, 30 Jul 97 19:16:00 EDT
My name is Thorsten Schiller and I have taken over responsibility from
John Dahms for the debugger project here at Sybase.
We made the switch to the 1.1.3 JDK recently and have been experiencing
some undesirable VM behavior - namely that it appears to "hang".
As you may remember, we use JNI and the RemoteDebugger interface to
implement our PowerJ debugger. I have traced the execution down into the
Agent.class and every time the VM hangs during one of the native calls
into the VM in that class. If I run the same sample using the 1.1.2 VM,
everything works correctly, so it does appear to be a new problem
introduced with 1.1.3.
I have attached a JDB sample that illustrates the problem. Further
instructions are contained in the sample.
Needless to say, we are currently in a position where 1.1.3 debugging
simply does not work so a quick resolution would be appreciated.
Thanks!
Thorsten
[[ JDKBUG~1.JAV : 6 in JDKBUG~1.JAV ]][[ JDKBUG~1.HTM : 7 in JDKBUG~1.HTM
]]
/*
* 07/30/97 JDK 1.1.3
*
* Starting with JDK 1.1.3, we have been having problems with the VM
* "hanging". The included sample demonstrates a scenario in which the
* 1.1.3 VM hangs. My first instinct was that the VM was deadlocking
* itself. However, I've meanwhile noticed that, while numerous, the
* number of iterations requires to produce the "hang" remains constant
* implying that an internal VM datastructure is experiencing an "overrun"
* of some sort.
*
* To reproduce:
*
* javac -g JKDBug1b.java
* jdb sun.applet.AppletViewer JDKBug1b.html
* > stop in JDKBug1b.createAppletForm
* > run
* > step
* > where 4
* .
* .
* .
* [ it requires 36 "where 4"'s to hang on my machine ]
* .
* .
* .
* > where 4
*
* Our debugger uses JNI and the RemoteDebugger interface. This problem
* was not seen prior to 1.1.3 and identical test cases will fail if
* using the 1.1.3 VM and pass with the 1.1.2 VM.
*/
class JDKBug1a extends java.applet.Applet
{
public boolean create() throws java.lang.Exception
{
return true;
}
public synchronized void destroy()
{
}
public JDKBug1a()
{
super();
}
}
public class JDKBug1b extends JDKBug1a
{
public JDKBug1b()
{
super();
}
public void init()
{
super.init();
addNotify();
createAppletForm();
}
public void createAppletForm()
{
try {
create();
} catch ( java.lang.Exception __e ) { System.err.println( __e.toString() + " " + __e.getMessage() ); }
}
public static void main(String args[])
{
}
}
<title>JDKBug1b</title>
<hr>
<applet code=JDKBug1b.class width=395 height=428 id=applet>
</applet>
<hr>
From: "Schiller,Thorsten" <###@###.###>
To: "'wyant'" <###@###.###>
Subject: JDK 1.1.3 Bug
Date: Wed, 30 Jul 97 19:16:00 EDT
My name is Thorsten Schiller and I have taken over responsibility from
John Dahms for the debugger project here at Sybase.
We made the switch to the 1.1.3 JDK recently and have been experiencing
some undesirable VM behavior - namely that it appears to "hang".
As you may remember, we use JNI and the RemoteDebugger interface to
implement our PowerJ debugger. I have traced the execution down into the
Agent.class and every time the VM hangs during one of the native calls
into the VM in that class. If I run the same sample using the 1.1.2 VM,
everything works correctly, so it does appear to be a new problem
introduced with 1.1.3.
I have attached a JDB sample that illustrates the problem. Further
instructions are contained in the sample.
Needless to say, we are currently in a position where 1.1.3 debugging
simply does not work so a quick resolution would be appreciated.
Thanks!
Thorsten
[[ JDKBUG~1.JAV : 6 in JDKBUG~1.JAV ]][[ JDKBUG~1.HTM : 7 in JDKBUG~1.HTM
]]
/*
* 07/30/97 JDK 1.1.3
*
* Starting with JDK 1.1.3, we have been having problems with the VM
* "hanging". The included sample demonstrates a scenario in which the
* 1.1.3 VM hangs. My first instinct was that the VM was deadlocking
* itself. However, I've meanwhile noticed that, while numerous, the
* number of iterations requires to produce the "hang" remains constant
* implying that an internal VM datastructure is experiencing an "overrun"
* of some sort.
*
* To reproduce:
*
* javac -g JKDBug1b.java
* jdb sun.applet.AppletViewer JDKBug1b.html
* > stop in JDKBug1b.createAppletForm
* > run
* > step
* > where 4
* .
* .
* .
* [ it requires 36 "where 4"'s to hang on my machine ]
* .
* .
* .
* > where 4
*
* Our debugger uses JNI and the RemoteDebugger interface. This problem
* was not seen prior to 1.1.3 and identical test cases will fail if
* using the 1.1.3 VM and pass with the 1.1.2 VM.
*/
class JDKBug1a extends java.applet.Applet
{
public boolean create() throws java.lang.Exception
{
return true;
}
public synchronized void destroy()
{
}
public JDKBug1a()
{
super();
}
}
public class JDKBug1b extends JDKBug1a
{
public JDKBug1b()
{
super();
}
public void init()
{
super.init();
addNotify();
createAppletForm();
}
public void createAppletForm()
{
try {
create();
} catch ( java.lang.Exception __e ) { System.err.println( __e.toString() + " " + __e.getMessage() ); }
}
public static void main(String args[])
{
}
}
<title>JDKBug1b</title>
<hr>
<applet code=JDKBug1b.class width=395 height=428 id=applet>
</applet>
<hr>
- duplicates
-
JDK-4061955 AppletViewer hangs under JDB in sun_awt_windows_WComponentPeer__dispose
-
- Closed
-