JDK-4284261 : (1.1) Robot tests will not build remotely for JCK: hang on exit from exec'd proc
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 1999-10-24
  • Updated: 2001-11-02
  • Resolved: 2001-11-02
Related Reports
Relates :  
Relates :  
Description
Robot tests fail JCK batch builds 

TEsts which compile and execute without error using JavaTest, will
not batch build.  This problem only occurs for tests which run in the 
separate process -- or JCK "multiJVM" mode. In building in batch, 
display and xhost are correctly set. The tests correctly exec a process,
and actually pass, but they each hang and timeout when they perform a
Status.exit , and report an overall JCK failed status. The overall failure
 reported to the log file is:
 
result: Failed. Program `/re/promoted/jdk/1.3/FCS/L/binary/solaris/
bin/java' interrupted! (timed out?)

The JCK also builds tests in the same JVM space (JCK "singleJVM" mode) and 
these tests build without problem. Builds are only done on Solaris.

After the first round of failures, Robot delays were set in the 
test and individual tests could be built for the JCK, however, 
when run in a small batch of 5, they failed as above. Including 
setAutoDelay to the maximum setting as well as setAutoWaitForIDle 
did not help. A mix of both auto settings and additional manual 
delay produced one success when run in batch but tweaking individual 
tests to build is unreliable. Changing the size of the build could introduce
more timing failures if these are timing failures at all.

For individual compiles and executes, these tests do not require any 
delays or waits.

It is possible that the autowaits and autodelays do not work for
the remotely exec' process. 

It is possibly related to Robot bug 4251318 -- there had been a fix to 
allow for remote displays over xconnections. 

Comments
EVALUATION Below is the evaluation by ###@###.###. Based on this evaluation, I am reassigning the bug to classes_io. I have attached three files that can be used as a test case (mentioned below). Note: This bug occurs because the JCK script runs its harness with JDK1.1.6. When JDK1.2 or later is used, this problem does not exist. So, in that sense, this bug is not reproducible since 1.2. Evaluation follows: I've assembled simple test emulating robot behavior. It consists of ProcTest.java and parent.c You need to set "test.src" property to run test. The problem is the java framework doesn't detects child process death in some special case. So test freezes on 1.1.6 and 1.1.8 with thread dump: "stderr reader pid=12029" (TID:0xfdf04130, sys_thread_t:0xfee31db8, state:CW) prio=5 java.io.FileInputStream.read(FileInputStream.java) java.lang.ProcessInputStream.run(UNIXProcess.java) java.lang.Thread.run(Thread.java) "stdout reader pid=12029" (TID:0xfdf04180, sys_thread_t:0xfee61db8, state:CW) prio=5 java.io.FileInputStream.read(FileInputStream.java) java.lang.ProcessInputStream.run(UNIXProcess.java) java.lang.Thread.run(Thread.java) "process reaper" (TID:0xfdf03fa0, sys_thread_t:0xfee91db8, state:CW) prio=5 java.lang.Thread.run(Thread.java) "Finalizer thread" (TID:0xfdf00208, sys_thread_t:0xfeec1db8, state:CW) prio=1 "Async Garbage Collector" (TID:0xfdf00250, sys_thread_t:0xfeef1db8, state:CW) prio=1 "Idle thread" (TID:0xfdf00298, sys_thread_t:0xfefc1db8, state:R) prio=0 *current thread* "Clock" (TID:0xfdf00088, sys_thread_t:0xfeff1db8, state:CW) prio=12 "main" (TID:0xfdf000b0, sys_thread_t:0x43bd8, state:CW) prio=5 java.io.PipedInputStream.read(PipedInputStream.java) java.lang.ProcessInputStream.read(UNIXProcess.java) ProcTest.main(ProcTest.java:10) Monitor Cache Dump: <unknown key> (0xfeef1db8): <unowned> Waiting to be notified: "Async Garbage Collector" (0xfeef1db8) java.lang.ProcessInputStream@FDF04240/FDF4FC08: <unowned> Waiting to be notified: "main" (0x43bd8) The test exits on 1.2 and later builds. The issue is traced down to sysReadFD called from java_io_FileInputStream_read. Since 1.2 this call is changed to JVM_Read. During my investigations i've found confusing problem with PipedInputStream. This class represents tail of pipe and don't have information about his head before first write. So first read can freeze forever. eric.hawkes@eng 1999-11-29 It is not unreasonable to require the JCK tests to be run from a 1.2 or later VM when testing version 1.3 of the JDK. The issues with PipedInputStream have been dealt with. See bug reports 4143704 and 4131126. michael.mccloskey@eng 1999-11-30
30-11-1999