Here is the prstat.log output:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
  1005 gtee 66M 7728K sleep 59 0 0:47:54 0.1% mixer_applet2/1
  6979 gtee 101M 84M sleep 59 0 0:00:34 0.1% java/36
   487 gtee 38M 9780K sleep 58 0 0:23:01 0.1% Xorg/1
   624 gtee 10M 2796K sleep 59 0 0:14:31 0.0% gconfd-2/1
   999 gtee 69M 7888K sleep 59 0 0:11:32 0.0% gnome-netstatus/1
  8698 gtee 1472K 896K sleep 9 0 0:00:00 0.0% sh/1
  8702 gtee 3408K 2580K cpu0 19 0 0:00:00 0.0% prstat/1
   951 gtee 80M 9320K sleep 59 0 0:07:59 0.0% gnome-panel/1
     1 root 2496K 656K sleep 59 0 0:00:08 0.0% init/1
  8095 gtee 86M 62M sleep 59 0 0:00:01 0.0% java/12
  8094 gtee 86M 62M sleep 59 0 0:00:01 0.0% java/12
   976 oemora 11M 2940K sleep 59 0 0:03:10 0.0% perl/1
   528 root 15M 1580K sleep 59 0 0:03:47 0.0% x11vnc/1
 29695 root 3408K 1408K sleep 59 0 0:00:00 0.0% agent.sh/1
   168 root 10M 4088K sleep 59 0 0:01:30 0.0% nscd/36
 NPROC USERNAME SWAP RSS MEMORY TIME CPU
    31 gtee 464M 306M 15% 1:46:51 0.4%
    44 root 77M 27M 1.3% 0:07:14 0.0%
     2 oemora 48M 31M 1.5% 0:08:43 0.0%
     1 lp 984K 1064K 0.1% 0:00:00 0.0%
     1 smmsp 1136K 2268K 0.1% 0:00:01 0.0%
Total: 85 processes, 310 lwps, load averages: 0.02, 0.02, 0.23
# Host info: SunOS vmsqe-amd-02 5.10 Generic_141445-09 i86pc i386 i86pc

The load average shows that this machine is NOT swamped.

The ps.log file didn't show anything unusual.

Here is the vmstat.log file:

kthr memory page disk faults cpu
 r b w swap free re mf pi po fr de sr f0 s0 s1 -- in sy cs us sy id
 0 0 0 5311704 1458992 132 686 46 13 15 0 18 -0 -0 8 0 540 1539 322 6 1 92
 0 0 0 5003140 1181524 316 1098 39 8 8 0 0 0 0 14 0 650 2851 735 1 2 97
# Host info: SunOS vmsqe-amd-02 5.10 Generic_141445-09 i86pc i386 i86pc
The following tests timed out in the 2012.08.06 RT_Baseline nightly:

    nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM004
    nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM005

The timeouts present with following exit status:

[2012-08-07T04:36:17.21] # Test level exit status: 151
# Host info: SunOS vmsqe-amd-02 5.10 Generic_141445-09 i86pc i386 i86pc

[2012-08-07T04:36:17.45] # Test level exit status: 151
# Host info: SunOS vmsqe-amd-02 5.10 Generic_141445-09 i86pc i386 i86pc

I'm filing this bug to record the sighting and to document
some of the analysis/hunting techniques.

Here's the configuration info:

Host: vmsqe-amd-02, AMD x86 2000 MHz, 2 cores, 2G, Solaris / Solaris 10, i86pc
JDK: Java(TM) SE Runtime Environment 1.7.0_06 b22 (1.7.0_06-fastdebug-b22)
VM: Java HotSpot(TM) Client VM 24.0 b20 (24.0-b20-internal-201208061641.ddaugher.merge_main_to_rt_b-fastdebug)
Options: -client -Xmixed -XX:DefaultMaxRAMFraction=8 -XX:ReservedCodeCacheSize=256M


Here are some observations about the createVM004 timeout.

In the .log file:

[2012-08-07T04:05:00.32] ${JAVA} ${JAVA_OPTS} ${EXECUTE_CLASS} -stressTime 30 -verbose -arch=solaris-i586 -waittime=5 -debugee.vmkind=java -transport.address=dynamic "-debugee.vmkeys=-client -Xmixed -XX:DefaultMaxRAMFraction=8 -XX:ReservedCodeCacheSize=256M"
[2012-08-07T04:05:00.32] # Actual: /export/local/common/jdk/baseline/solaris-i586/bin/java -client -Xmixed -XX:DefaultMaxRAMFraction=8 -XX:ReservedCodeCacheSize=256M -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck=1 nsk.jdi.VirtualMachineManager.createVirtualMachine.createVM004 -stressTime 30 -verbose -arch=solaris-i586 -waittime=5 -debugee.vmkind=java -transport.address=dynamic "-debugee.vmkeys=-client -Xmixed -XX:DefaultMaxRAMFraction=8 -XX:ReservedCodeCacheSize=256M"
[2012-08-07T04:35:25.88] ==> nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM004 test...
[2012-08-07T04:35:25.88] ==> Test checks that virtualMachineManager.createVirtualMachine(Connection, Process) method
[2012-08-07T04:35:25.88] ==> creates Virtual Machine properly when 'Process' argument is null.
[2012-08-07T04:35:25.88] --> createVM004: Start Listening for target VM...
[2012-08-07T04:35:25.88] --> createVM004: PROCESS is being created:
[2012-08-07T04:35:25.88] --> Command to run: /export/local/common/jdk/baseline/solaris-i586/jre/bin/java -client -Xmixed -XX:DefaultMaxRAMFraction=8 -XX:ReservedCodeCacheSize=256M -Xdebug -Xrunjdwp:transport=dt_socket,address=32814 nsk.jdi.VirtualMachineManager.createVirtualMachine.CreateVM004_TargetVM
[2012-08-07T04:35:25.88] --> createVM004: Accepting launched target VM...


The above .log output shows typical test setup messages and the
launching the debuggee VM. The last .log output line above comes
from the following code in creadVM004.java:

            logOnVerbose(infoLogPrefixHead + "PROCESS is being created:");
            logOnVerbose(infoLogPrefix + "Command to run: " + commandToRun);

            debugee = binder.startLocalDebugee(commandToRun);
            debugee.redirectOutput(logHandler);
            processToRun = debugee.getProcess();

            logOnVerbose(infoLogPrefixHead + "Accepting launched target VM...");
            try {
                testTransportServiceConnection
                    = testTransportService.accept(testTransportServiceListenKey, 0, 0);
            } catch ( IOException ioExcept ) {

Since there is no further output in the .log file from the
debugger/test process, it looks like it is still in the
testTransportService.accept() call above. The debugger
thread dump at the timeout point confirms this:

[2012-08-07T04:35:25.88] "main" prio=3 tid=0x0806b800 nid=0x2 runnable [0xfcc6e000]
[2012-08-07T04:35:25.88] java.lang.Thread.State: RUNNABLE
[2012-08-07T04:35:25.88] JavaThread state: _thread_in_native
[2012-08-07T04:35:25.88] Thread: 0x0806b800 [0x 2] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[2012-08-07T04:35:25.88] JavaThread state: _thread_in_native
[2012-08-07T04:35:25.88] at java.net.PlainSocketImpl.socketAccept(Native Method)
[2012-08-07T04:35:25.88] at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
[2012-08-07T04:35:25.88] at java.net.ServerSocket.implAccept(ServerSocket.java:522)
[2012-08-07T04:35:25.88] at java.net.ServerSocket.accept(ServerSocket.java:490)
[2012-08-07T04:35:25.88] at nsk.jdi.VirtualMachineManager.createVirtualMachine.CreateVM004_TranspServ.accept(CreateVM004_TranspServ.java:277)
[2012-08-07T04:35:25.88] at nsk.jdi.VirtualMachineManager.createVirtualMachine.createVM004.runThis(createVM004.java:142)
[2012-08-07T04:35:25.88] at nsk.jdi.VirtualMachineManager.createVirtualMachine.createVM004.run(createVM004.java:67)
[2012-08-07T04:35:25.88] at nsk.jdi.VirtualMachineManager.createVirtualMachine.createVM004.main(createVM004.java:62)



The .log output below shows that the debuggee has no output until
a thread dump is requested at the timeout point (30 minutes after
the test started):

[2012-08-07T04:35:25.88] debugee.stdout> 2012-08-07 08:35:17
[2012-08-07T04:35:25.88] debugee.stdout> Full thread dump Java HotSpot(TM) Client VM (24.0-b20-internal-201208061641.ddaugher.merge_main_to_rt_b-fastdebug mixed mode):
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> "Signal Dispatcher" daemon prio=3 tid=0x081bf800 nid=0x6 waiting on condition [0x00000000]
[2012-08-07T04:35:25.88] debugee.stdout> java.lang.Thread.State: RUNNABL
[2012-08-07T04:35:25.88] E
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_blocked
[2012-08-07T04:35:25.88] debugee.stdout> Thread: 0x081bf800 [0x 6] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_blocked
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> "Finalizer" daemon prio=3 tid=0x0819a400 nid=0x5 in Object.wait() [0xfca7e000]
[2012-08-07T04:35:25.88] debugee.stdout> java.lang.Thread.State: WAITING (on object monitor)
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_blocked
[2012-08-07T04:35:25.88] debugee.stdout> Thread: 0x0819a400 [0x 5] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_blocked
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.Object.wait(Native Method)
[2012-08-07T04:35:25.88] debugee.stdout> - waiting on <0xe0205698> (a java.lang.ref.ReferenceQueue$Lock)
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
[2012-08-07T04:35:25.88] debugee.stdout> - locked <0xe0205698> (a java.lang.ref.ReferenceQueue$Lock)
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.ref.Finalize
[2012-08-07T04:35:25.88] r$FinalizerThread.run(Finalizer.java:177)
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> "Reference Handler" daemon prio=3 tid=0x08198c00 nid=0x4 in Object.wait() [0xec97d000]
[2012-08-07T04:35:25.88] debugee.stdout> java.lang.Thread.State: WAITING (on object monitor)
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_blocked
[2012-08-07T04:35:25.88] debugee.stdout> Thread: 0x08198c00 [0x 4] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_blocked
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.Object.wait(Native Method)
[2012-08-07T04:35:25.88] debugee.stdout> - waiting on <0xe0205270> (a java.lang.ref.Reference$Lock)
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.Object.wait(Object.java:503)
[2012-08-07T04:35:25.88] debugee.stdout> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
[2012-08-07T04:35:25.88] debugee.stdout> - locked <0xe0205270> (a java.lang.ref.Reference$Lock)
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> "main" prio=3 tid=0x0806bc00 nid=0x2 runnable [0x00000000]
[2012-08-07T04:35:25.88] debugee.stdout> java.lang.Thread.State: RUNNABLE
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_in_native
[2012-08-07T04:35:25.88] debugee.stdout> Thread: 0x0806bc0
[2012-08-07T04:35:25.88] 0 [0x 2] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_in_native
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> "VM Thread" prio=3 tid=0x08196800 nid=0x3 runnable
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> Compiler thread printing unimplemented.
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> JNI global references: 346
[2012-08-07T04:35:25.88] debugee.stdout>
[2012-08-07T04:35:25.88] debugee.stdout> Heap
[2012-08-07T04:35:25.88] debugee.stdout> def new generation total 4928K, used 281K [0xe0200000, 0xe0750000, 0xe2ca0000)
[2012-08-07T04:35:25.88] debugee.stdout> eden space 4416K, 6% used [0xe0200000, 0xe02464a8, 0xe0650000)
[2012-08-07T04:35:25.88] debugee.stdout> from space 512K, 0% used [0xe0650000, 0xe0650000, 0xe06d0000)
[2012-08-07T04:35:25.88] debugee.stdout> to space 512K, 0% used [0xe06d0000, 0xe06d0000, 0xe0750000)
[2012-08-07T04:35:25.88] debugee.stdout> tenured generation total 10944K, used 0K [0xe2ca0000, 0xe3750000, 0xe8200000)
[2012-08-07T04:35:25.88] debugee.stdout> the space 10944K, 0% used [0xe2ca0000, 0xe2ca0000, 0xe2ca0200, 0xe3750000)
[2012-08-07T04:35:25.88] debugee.stdout> compacting perm gen total 12288K, used 1510K [0xe8200000, 0xe8e00000,
[2012-08-07T04:35:25.88] 0xec200000)
[2012-08-07T04:35:25.88] debugee.stdout> the space 12288K, 12% used [0xe8200000, 0xe8379aa8, 0xe8379c00, 0xe8e00000)
[2012-08-07T04:35:25.88] debugee.stdout> No shared spaces configured.
[2012-08-07T04:35:25.88] debugee.stdout>


Here is the debuggee test program, CreateVM004_TargetVM.java:

public class CreateVM004_TargetVM {

    static final int STATUS_PASSED = 0;
    static final int STATUS_FAILED = 2;
    static final int STATUS_TEMP = 95;


    public static void main (String argv[]) {
        System.exit(STATUS_PASSED + STATUS_TEMP);
    }


} // end of CreateVM004_TargetVM class

which explains why there is no debuggee output until the
thread dump is requested. This part of the debuggee's
thread dump is interesting:

[2012-08-07T04:35:25.88] debugee.stdout> "main" prio=3 tid=0x0806bc00 nid=0x2 runnable [0x00000000]
[2012-08-07T04:35:25.88] debugee.stdout> java.lang.Thread.State: RUNNABLE
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_in_native
[2012-08-07T04:35:25.88] debugee.stdout> Thread: 0x0806bc0
[2012-08-07T04:35:25.88] 0 [0x 2] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[2012-08-07T04:35:25.88] debugee.stdout> JavaThread state: _thread_in_native

There is no call stack for the main thread.


So let's try to find out more about the debuggee VM.

The .jinfo log has the following in it:

Attaching to process ID 8098, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 24.0-b20-internal-201208061641.ddaugher.merge_main_to_rt_b-fastdebug
Java System Properties:

java.runtime.name = Java(TM) SE Runtime Environment
java.vm.version = 24.0-b20-internal-201208061641.ddaugher.merge_main_to_rt_b-fastdebug
sun.boot.library.path = /export/local/common/jdk/baseline/solaris-i586/jre/lib/i386
java.vendor.url = http://java.oracle.com/
java.vm.vendor = Oracle Corporation
path.separator = :
file.encoding.pkg = sun.io
java.vm.name = Java HotSpot(TM) Client VM
sun.os.patch.level = unknown
sun.java.launcher = SUN_STANDARD
user.dir = /export/local/85269.JAVASE.NIGHTLY.VM.RT_Baseline.2012-08-06.solaris-i586_vm__client_mixed_nsk.quick-jdi.testlist.runTests/results/ResultDir/createVM004
java.vm.specification.name = Java Virtual Machine Specification
java.runtime.version = 1.7.0_06-fastdebug-b22
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
os.arch = x86
java.endorsed.dirs = /export/local/common/jdk/baseline/solaris-i586/jre/lib/endorsed
java.io.tmpdir = /var/tmp/
line.separator =

java.vm.specification.vendor = Oracle Corporation
os.name = SunOS
sun.jnu.encoding = ISO646-US
java.library.path = /export/local/common/jdk/baseline/solaris-i586/jre/lib/i386/client:/usr/jdk/packages/lib/i386:/lib:/usr/lib
java.specification.name = Java Platform API Specification
java.class.version = 51.0
sun.management.compiler = HotSpot Client Compiler
os.version = 5.10
user.home = /export/local/home/gtee
user.timezone =
java.awt.printerjob = sun.print.PSPrinterJob
file.encoding = ISO646-US
java.specification.version = 1.7
user.name = gtee
java.class.path = /export/local/85269.JAVASE.NIGHTLY.VM.RT_Baseline.2012-08-06.solaris-i586_vm__client_mixed_nsk.quick-jdi.testlist.runTests/results/ResultDir/createVM004:/export/local/common/testbase/7/vm/vm/bin/classes:/export/local/common/jdk/baseline/solaris-i586/lib/tools.jar
java.vm.specification.version = 1.7
sun.arch.data.model = 32
sun.java.command = nsk.jdi.VirtualMachineManager.createVirtualMachine.CreateVM004_TargetVM
java.home = /export/local/common/jdk/baseline/solaris-i586/jre
user.language = en
java.specification.vendor = Oracle Corporation
awt.toolkit = sun.awt.X11.XToolkit
java.vm.info = mixed mode
java.version = 1.7.0_06-fastdebug
java.ext.dirs = /export/local/common/jdk/baseline/solaris-i586/jre/lib/ext:/usr/jdk/packages/lib/ext
sun.boot.class.path = /export/local/common/jdk/baseline/solaris-i586/jre/lib/resources.jar:/export/local/common/jdk/baseline/solaris-i586/jre/lib/rt.jar:/export/local/common/jdk/baseline/solaris-i586/jre/lib/sunrsasign.jar:/export/local/common/jdk/baseline/solaris-i586/jre/lib/jsse.jar:/export/local/common/jdk/baseline/solaris-i586/jre/lib/jce.jar:/export/local/common/jdk/baseline/solaris-i586/jre/lib/charsets.jar:/export/local/common/jdk/baseline/solaris-i586/jre/lib/jfr.jar:/export/local/common/jdk/baseline/solaris-i586/jre/classes
java.vendor = Oracle Corporation
file.separator = /
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
sun.io.unicode.encoding = UnicodeBig
sun.cpu.endian = little
sun.cpu.isalist =

VM Flags:

-Xmixed -XX:DefaultMaxRAMFraction=8 -XX:ReservedCodeCacheSize=256M -Xdebug -Xrunjdwp:transport=dt_socket,address=32814

The VM Flags part confirms that PID 8098 is the debuggee VM
and the fact that we were able to attach and get this info
means that the debuggee VM process is up and running.

The .jstack log muddies the waters a bit:

8098: Unable to open door: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

The .jstack.fml log helps clear things up a bit:

Attaching to process ID 8098, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 24.0-b20-internal-201208061641.ddaugher.merge_main_to_rt_b-fastdebug
Deadlock Detection:

can't print deadlock information: fec56308

The .jstat.gccause log doesn't help:

Could not synchronize with target

The .pstack log file doesn't help:

pstack: cannot examine 8098: process is traced

So we don't have native call stacks/thread dumps so we don't
know exactly what's going on.
The createVM005 failure is similar, but not identical. That
test's .log file does not contain any debuggee output so
there is no thread dump output from the timeout. However,
the .jstack log shows the thread dump for that debuggee VM.


Since the debugger VM is still in the accept() call, these
two tests never got past the infrastructure setup phase.

Also, createVM00[123] each took less than 3 seconds to
finish before createVM004 and createVM005 timed out.
Whatever happened here wasn't due to an overloaded system.

According to tonga.output/Tonga.log.log, this run had
concurrency enabled:

[2012-08-07T03:52:19.69] TEST_CONCURRENCY_DYN="true"
[2012-08-07T03:52:19.69] # Actual: TEST_CONCURRENCY_DYN=true
[2012-08-07T03:52:19.69] TEST_CONCURRENCY_MAX="6"
[2012-08-07T03:52:19.69] # Actual: TEST_CONCURRENCY_MAX=6

The tonga.output/Tonga.log.out file also has interesting info:

TEST 466/562 466/562 nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM001 PASS
TEST 467/562 467/562 nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM002 PASS
TEST 468/562 468/562 nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM003 PASS
EXCEPTION: Thread[StreamConnectionThread (filename = /export/local/85269.JAVASE.NIGHTLY.VM.RT_Baseline.2012-08-06.solaris-i586_vm__client_mixed_nsk.quick-jdi.testlist.runTests/results/ResultDir/createVM004/createVM004.eout, appname = createVM004),5,main] : java.io.IOException: Stream closed
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:255)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at tonga.util.output.thread.InterruptibleChannel.read(StreamConnectionThread.java:190)
at tonga.util.output.thread.StreamConnectionThread.run(StreamConnectionThread.java:66)
EXCEPTION: Thread[StreamConnectionThread (filename = /export/local/85269.JAVASE.NIGHTLY.VM.RT_Baseline.2012-08-06.solaris-i586_vm__client_mixed_nsk.quick-jdi.testlist.runTests/results/ResultDir/createVM005/createVM005.eout, appname = createVM005),5,main] : java.io.IOException: Stream closed
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:255)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at tonga.util.output.thread.InterruptibleChannel.read(StreamConnectionThread.java:190)
at tonga.util.output.thread.StreamConnectionThread.run(StreamConnectionThread.java:66)
TEST 469/562 469/562 nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM004 FAIL(TIMEOUT)
TEST 470/562 470/562 nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM005 FAIL(TIMEOUT)
TEST 471/562 471/562 nsk/jdi/VMCannotBeModifiedEx/_itself_/canntbemod001 PASS

I don't know whether the exceptions that are shown above are due to
the timeout failures or whether they were the cause of the timeout
failures.