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>
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
Wolfgang, as a unix person, what do think is causing this? How do programs really change when they are run in the background?
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=""
I would think it a side effect of Jesse's (relatively) recent work... not finger-pointing, but hoping to attract his attention. ;)
Yes, it could be related to input handling stuff... haven't had a chance to look at it just yet.
(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!
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
(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.
what if you start the process with </dev/null ?
(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.
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.
I've turned that into a documentation bug and will document the inputstring="" workaround in several places.
well, not really fixed, but at least documented. subversion revision 677899
*** Bug 45638 has been marked as a duplicate of this bug. ***
*** Bug 37887 has been marked as a duplicate of this bug. ***
*** Bug 38893 has been marked as a duplicate of this bug. ***
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.
*** Bug 40014 has been marked as a duplicate of this bug. ***
*** Bug 41024 has been marked as a duplicate of this bug. ***
*** Bug 36903 has been marked as a duplicate of this bug. ***
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?