[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT

["cyberflex at mail dot ru" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #13 from cyberflex at mail dot ru  2007-08-31 09:42 -------
(In reply to comment #12)
> Does GCJ's behavior differ from Sun's in this test?
> 

Well.. tried that (jdk1.6 i386)
Answer is: at this point NOT. So this is "not an issue"

But while performing this test I found a slight difference
in treating of output streams of process for which the waitFor returned.

GCJ-compiled program may use output stream of such process: use available(),
read(), readLine() e.t.c.
In out case readLine() returns null

While JDK-compiled class running in SUN's JVM (both are 1.6 version) throws
exception:
Exception in thread "main" java.io.IOException: Stream closed
        at
java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:134)
        at java.io.BufferedInputStream.available(BufferedInputStream.java:381)
        at java.io.FilterInputStream.available(FilterInputStream.java:142)
        at test.main(test.java:19)


This looks like to be a slight deviation from standard in GCJ :(

But that's NOT the problem I stated initially and is to be dealt in othe bug
(IMHO)

When running shell script the rfcomm program replaces it in process list
(accordingly POSIX or something likes that) so I always erroniously considered
not killed rfcomm as NOT killed bt_connect.sh

I feal myself ashamed, I apologize once again ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218