Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7189981

createVM004 and createVM005 time out intermittently

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      x86
    • OS:
      solaris

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            dcubed Daniel Daugherty
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated:
              Imported:
              Indexed: