Under Windows, a process inherits handles even when spawned using the Exec task with the spawn attribute. This makes an Exec task that calls another Exec task with the spawn attribute to block until the spawned process exits. The source of the problem may be in the JVM where a spawned process may be created using the Win32 API CreateProcess with the bInheritHandles attribute set to TRUE, while it should be FALSE for spawned processes. A workaround can be to insert a process that will spawn the original process with the bInheritHandles attribute set to FALSE. See attached Ant script demonstrating the environment, the problem and the workaround.
Created attachment 18934 [details] Ant script demonstrating the environment, the problem and the
Thanks for the report. I think that this is the same probles http://issues.apache.org/bugzilla/show_bug.cgi?id=5003 except that you set the spawn attribute and still see the problem
But what could we do in Ant to get around the original problem?
Hello Matt, we could make a slightly modified version of this CreateDetachedProcess.cpp which would just create a really detached process without inherited handles, and ship Ant with CreateDetachedProcess.exe in the bin directory, and wrap spawning under Win32 with this CreateDetachedProcess.exe. The CreateDetachedProcess.cpp in the attached zip file has this line : LPTSTR lpCommandLine = "Notepad"; if instead we write the Microsoft VC++ equivalent of : LPTSTR lpCommandLine = join(argv, " "); // do not know which idiom we could use here then we would have something. The other thing we can do is have a look whether Sun has done some work on this issue in JDK 1.6. Else one of us could write in the BugParade, so that the issue gets addressed. Regards, Antoine
I'd rather push this towards Sun and Harmony. I dont want to get into the problem of rewriting the java process API. Actually, I do, but not now; not in Ant. There's lots of things in ::CreateProcess() that Java hides, just as there's some options in ::LoadLibrary() that I'd have but which Sun dont expose in the JNI library loading.
Yes, I thought we had had discussion in the past that steered towards the decision of whether to include C (or Cpp or whatever) code in Ant, and usually those were met with general reluctance. ;)
I reproduced the problem with Java 1.6 Beta2 and I started the thread http://forum.java.sun.com/thread.jspa?threadID=772669 titled "Spawned process blocks grand parent" regarding this issue with a Java only example.
I submitted the problem reported in the thread http://forum.java.sun.com/thread.jspa?threadID=772669 titled "Spawned process blocks grand parent" as a bug on the Java Bug Database at http://bugs.sun.com. It has been accepted as a new bug and entered the bug into the internal bug tracking system under Bug Id: 6481278. You can vote for the bug at http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6481278.
For the record: Peter Reilly seems to think that there is a connection between this and bug 5003 and bug 37787.
Created attachment 19022 [details] Runs arguments with bIneheritHandle to FALSE Allows to test if setting the bInheritHandles to FALSE will fix problem related to this. To use it, replace the executable in the exec task with this program and insert the old executable as first argument. Eg: <exec executable="notepad"> <arg file="test.txt"/> </exec> would become: <exec executable="SpawnDetachedProcess"> <arg value="notepad"/> <arg file="test.txt"/> </exec>
You can use the forget task from ant-contrib to emulate this. The forget task simply a <sequential> that executes its tasks in a new thread, the daemon attribute of which is true. <ac:forget xmlns:ac="antlib:net.sf.antcontrib"> <exec executable="notepad.exe" spawn="true"/> </ac:forget>