Bug 152134 - BEA JVM blocks when trying to close child process's error stream
BEA JVM blocks when trying to close child process's error stream
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: java-1.4.2-bea (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On:
Blocks: 168424 168430
  Show dependency treegraph
 
Reported: 2005-03-25 00:41 EST by Thomas Fitzsimmons
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2006-0008
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-15 10:45:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
demonstrates BEA JVM blocking on InputStream.close (878 bytes, application/x-gzip)
2005-03-25 00:43 EST, Thomas Fitzsimmons
no flags Details

  None (edit)
Description Thomas Fitzsimmons 2005-03-25 00:41:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050308 Firefox/1.0.1 Fedora/1.0.1-5

Description of problem:
We're working with a Java application that launches an external process
via java.lang.Runtime.exec, then closes the child's stderr and stdout.  BEA's JVM blocks indefinitely when attempting to close the child's stderr.

Attached is a test case that demonstrates the problem.  When run under IBM's JVM, the test produces these results:

$ make build
mkdir -p build
javac -d build src/Parent.java
mkdir -p build
javac -d build src/Child.java

$ make run
java -classpath build Parent -classpath build Child
command=[/usr/local/jdk/jre/bin/java, -classpath, build, Child]
Attempting to close child's error stream.
Successfully closed child's error stream.

BEA's JVM produces these results:

$ java -version
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.5.0-0 (build ari-41062-20050215-0919-linux-ia32, Native Threads, GC strategy: parallel)

$ make run
java -classpath build Parent -classpath build Child
command=[/usr/local/jrockit-j2sdk1.4.2_05/jre/bin/java, -classpath, build, Child]
Attempting to close child's error stream.

The test case blocks indefinitely at this point, with the parent
process blocked trying to close the child's error stream.

Also, the child process does not respond to "kill -QUIT".  The parent process does respond to SIGQUIT by dumping stack traces for all of its active threads to the console.

Version-Release number of selected component (if applicable):
java-1.4.2-bea-1.4.2.04-1jpp_11rh

How reproducible:
Always

Steps to Reproduce:
1. untar test case
2. make build
3. make run


Actual Results:  JVM blocks when trying to close child's stderr.


Expected Results:  JVM should successfully close child's stderr.

Additional info:
Comment 1 Thomas Fitzsimmons 2005-03-25 00:43:39 EST
Created attachment 112342 [details]
demonstrates BEA JVM blocking on InputStream.close
Comment 2 Robert Ottenhag 2005-03-29 06:15:14 EST
Thanks for the report and small repro case. Please also add the exact OS-ARCH 
info on which you discovered the bug. Thanks. 
Comment 3 Johan Walles 2005-04-01 07:44:56 EST
I have so far been unable to reproduce this on a "Fedora Core release 3
(Heidelberg)".  Was that what you tried this on?  Can you add the output of "cat
/etc/redhat-release", "cat /etc/fedora-release" and "cat /proc/cpuinfo" here?

[johan@viper src_ariane]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.60GHz
stepping        : 6
cpu MHz         : 599.573
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush
dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
bogomips        : 1188.86

About the JRockit version number, you say that the RPM version  is
"java-1.4.2-bea-1.4.2.04-1jpp_11rh" and that "java -version" says:

"
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.5.0-0 (build
ari-41062-20050215-0919-linux-ia32, Native Threads, GC strategy: parallel)
"

Can you confirm that that RPM really contains that JRockit version?  In that
case we have a packaging problem on top of the other one (that I can't repro).

Where can I get hold of a binary of the exact version of JRockit you ran?
Comment 4 David Simms 2005-04-21 05:10:56 EDT
This is a bug we've already fixed and will be available in the next public release.

Workaround: drain the input streams before closing them.
Comment 5 Thomas Fitzsimmons 2005-12-08 11:48:11 EST
This bug is fixed by the packages in RHBA-2006:008-03 and RHBA-2006:009-02.  So
this will be fixed in RHEL3U7 and RHEL4U3.
Comment 6 Tom Kincaid 2006-01-03 15:43:33 EST
I verified this fix in the latest set of packages that are part of RHEL 4 U3.
Comment 10 Red Hat Bugzilla 2006-03-07 13:27:34 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0009.html
Comment 11 Red Hat Bugzilla 2006-03-15 10:45:43 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0008.html

Note You need to log in before you can comment on or make changes to this bug.