Bug 34461 - problems with core <java fork="true"> task
problems with core <java fork="true"> task
Status: RESOLVED FIXED
Product: Ant
Classification: Unclassified
Component: Documentation
1.6.3
PC Linux
: P2 normal with 3 votes (vote)
: 1.8.0
Assigned To: Ant Notifications List
:
: 36903 37887 38893 40014 41024 45638 (view as bug list)
Depends on: 24918
Blocks:
  Show dependency tree
 
Reported: 2005-04-14 23:11 UTC by Greg Gimler
Modified: 2014-02-17 13:52 UTC (History)
11 users (show)



Attachments
example program, describing the problem (276 bytes, text/x-java)
2005-10-07 10:52 UTC, Carsten Pfeiffer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Gimler 2005-04-14 23:11:16 UTC
I've noticed a subtle bug in the way ant 1.6.3 now forks off java processes. 
I've compared the behavior between 1.6.2 and 1.6.3.

My environment is red hat enterprise linux 3 with java 1.4.2. (see example code
at the bottom).  I run with the following command...

1) ant &

This executes an application that performs a sleep, then prints out
some text, followed by a wait call that should hang indefinitely.

In the background it will run and you will see the print statement in
1.6.2 but not 1.6.3.  If you hit enter you'll see that the job goes
into the "Stopped" state in 1.6.3.  If you put it back into the
foreground it will finish executing, it's only when you have it as a
background process that it misbehaves.


--- CODE STARTS HERE ----

// Test.java

public class Test {
 
        public static void main(String args[] ){
                try {
                        Thread.sleep(5000);
                } catch(InterruptedException ie) {}
                System.out.println("Running...");
                try {
                synchronized(Test.class) {
                        Test.class.wait();
                }
                } catch (InterruptedException ie) {}
 
        }
}

----------------build.xml-------------------------------------------

<project name="java-problem" default="java-problem" basedir=".">
        <target name="java-problem">
                <java classname="Test" fork="true">
                        <classpath>
                                <pathelement path="${basedir}"/>
                        </classpath>
                </java>
        </target> 
</project>
Comment 1 Wolfgang Baer 2005-09-27 22:30:57 UTC
Hi,

I can confirm this behaviour with ant 1.6.5. We got a bug report for
the debian ant package and my tests show that the java task with
fork="true" does not work in 1.6.5 anymore in the background.

For the debian bug report and possible followups and testcases
see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330292

Thanks,

Wolfgang
Comment 2 Steve Loughran 2005-09-28 10:24:51 UTC
Wolfgang, as a unix person, what do think is causing this?

How do programs really change when they are run in the background?
Comment 3 Steve Loughran 2005-09-28 14:21:04 UTC
Maybe this has been caused by the (excellent) work to hook up ant's input to
that of tasks. Does setting an empty input string in the java task make this go
away?

inputstring=""
Comment 4 Matt Benson 2005-09-28 19:43:20 UTC
I would think it a side effect of Jesse's (relatively) recent work... not 
finger-pointing, but hoping to attract his attention.  ;)
Comment 5 Jesse Glick 2005-09-28 20:31:25 UTC
Yes, it could be related to input handling stuff... haven't had a chance to look
at it just yet.
Comment 6 Carsten Pfeiffer 2005-09-29 11:45:34 UTC
(In reply to comment #3)  
> Does setting an empty input string in the java task make this go away?  
>   
> inputstring=""  
  
Yes, indeed, it does go away, then!  
Comment 7 Steve Loughran 2005-09-29 12:55:55 UTC
Ok, so it is an input hooking up thing. I guess when you run ant in the
background, the moment anything tries to listen to stdin it hangs until brought
to the fg.

question, is, what is doing the read? The sample app isnt, 

Now prior to 1.6.3, we werent routing stdin to forked java code; bug #24918 was
a patch to route stuff:
http://issues.apache.org/bugzilla/show_bug.cgi?id=24918
Comment 8 Carsten Pfeiffer 2005-09-29 18:39:51 UTC
(In reply to comment #7) 
> Ok, so it is an input hooking up thing. I guess when you run ant in the 
> background, the moment anything tries to listen to stdin it hangs until 
brought 
> to the fg. 
 
Yes. From bash's manpage: 
 
"Background processes which attempt to read from (write to) the terminal are 
sent a SIGTTIN (SIGTTOU) signal by the terminal driver, which, unless caught, 
suspends the process." 
 
Now I'm wondering how to detect this situation in java-land. When you try to 
read, you get an IOException: 
 
     [java] java.io.IOException: Unknown error 512 
     [java]     at java.io.FileInputStream.readBytes(Native Method) 
     [java]     at java.io.FileInputStream.read(FileInputStream.java:194) 
     [java]     at 
java.io.BufferedInputStream.fill(BufferedInputStream.java:183) 
     [java]     at java.io.BufferedInputStream.read1
(BufferedInputStream.java:222) 
     [java]     at 
java.io.BufferedInputStream.read(BufferedInputStream.java:277) 
     [java]     at java.io.FilterInputStream.read(FilterInputStream.java:90) 
     [java]     at 
org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:90) 
     [java]     at java.lang.Thread.run(Thread.java:534) 
 
but how would know if you can read or not? As soon as you attempt to read, 
you're being stopped SIGTTIN. 
 
> question, is, what is doing the read? The sample app isnt,  
[...] 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=24918 
 
See the above stacktrace. 
 
Java.setupRedirector() sets the inputStream for redirection, where it ends up 
in a StreamPumper (somewhere in Redirector.createStreams()). The StreamPumper 
immediately starts reading from the input stream, causing the SIGTTIN. 
Comment 9 Matt Benson 2005-09-29 20:58:51 UTC
what if you start the process with </dev/null ?
Comment 10 Carsten Pfeiffer 2005-09-29 21:31:35 UTC
(In reply to comment #9) 
> what if you start the process with </dev/null ? 
 
Then it works of course, as it won't read from the terminal in any case. 
Comment 11 Carsten Pfeiffer 2005-10-07 10:52:44 UTC
Created attachment 16616 [details]
example program, describing the problem

This is a tiny sample program, showing the source of this bug.
Compile and start it as 

java Problem &

You can observe with `ps', that the programm will be suspended immediately:
gis	 14963	5.7  0.7 213220  7984 pts/3    Tl   10:45   0:00 java Problem

So what is needed is the information when System.in.read() is possible and when
it isn't.
Comment 12 Stefan Bodewig 2008-07-16 09:10:08 UTC
I've turned that into a documentation bug and will document the inputstring="" workaround in several places.
Comment 13 Stefan Bodewig 2008-07-18 06:10:06 UTC
well, not really fixed, but at least documented.

subversion revision 677899
Comment 14 Matt Benson 2008-08-18 05:48:57 UTC
*** Bug 45638 has been marked as a duplicate of this bug. ***
Comment 15 Stefan Bodewig 2008-08-20 08:04:39 UTC
*** Bug 37887 has been marked as a duplicate of this bug. ***
Comment 16 Stefan Bodewig 2008-08-20 08:04:49 UTC
*** Bug 38893 has been marked as a duplicate of this bug. ***
Comment 17 Stefan Bodewig 2008-08-21 05:20:40 UTC
given the amount of other bug reports that can all be tracked down to the very same problem, I've add an FAQ for it.  svn revision 687724.
Comment 18 Stefan Bodewig 2008-08-21 05:25:58 UTC
*** Bug 40014 has been marked as a duplicate of this bug. ***
Comment 19 Stefan Bodewig 2008-08-21 05:29:15 UTC
*** Bug 41024 has been marked as a duplicate of this bug. ***
Comment 20 Stefan Bodewig 2008-08-22 04:42:37 UTC
*** Bug 36903 has been marked as a duplicate of this bug. ***
Comment 21 troy.harris 2010-05-28 14:49:33 UTC
The FAQ entry states that this can be a problem with <exec> tasks as well.  I am looking at the source for ant 1.7.0 and I can see the change that was made for Bug #24918 in the source for the <java> task.  It appears that I just need to comment out the following code in Java.java to remove the change:

/*
if (!spawn && input == null && inputString == null) {
     // #24918: send standard input to the process by default.
     redirector.setInputStream(
     new KeepAliveInputStream(getProject().getDefaultInputStream()));
}
*/

Is the only change required to remove the functionality provided by Bug #24918?

I don't see any such code in ExecTask.java, but the FAQ entry for the hang on StandradInput says this:

"When Ant forks a new process for example by using the <exec>, <apply> or <java> tasks, it will also start a new thread reading from standard input and sending everything that it has read to that process."

What else is required to build 1.7.0 without the fixes to hookup standard in on these tasks?