Never mind. This was my error. I had mistakenly thought that I all of the output would be captured while I waited for the child process to quit. Instead the parent has to obtain the child's stdout pistream and read from it while the child is running. Failure to do so may result in the buffer filling and the child hanging. Sorry for the fire drill... Best, -- Allen Cronce Begin forwarded message:

From: Allen Cronce Date: July 8, 2010 4:29:33 PM PDT To: boost-users@lists.boost.org Subject: [process] Child process hangs while capturing stdout

Hi all,

I'm not sure where to post this since boost.process is a candidate and not officially accepted to boost proper. If this should go elsewhere, please let me know.

We're seeing hangs when running child command line executables under Mac OS X (posix) while capturing stdout. It seems to happen more often when the command line child app is verbose and spitting out a lot of output.

To test this, I created a simple test app that outputs some number of random guids to cout. I then launched this child app from another test app using boost process, indicating that we're capturing stdout.

If I run the test with just a few guids outputted (like 100), it works fine. But if I tell the test app to output 1000 guids, the child app hangs every time, attempting to flush the output stream:

#0 0x96378249 in write$NOCANCEL$UNIX2003 () #1 0x963781ad in _swrite () #2 0x96376fdd in __sflush () #3 0x96376f79 in fflush () #4 0x91b1ecb2 in std::ostream::flush () #5 0x00005ae6 in main (argc=4, argv=0xbffff608)

If I launch the child app manually with the same parameters (i.e. 1000 iterations), rather than programmatically via boost process, it works fine.

The code I'm using to configure the environment of the test app is the following:

--snip-- // context - Inherit our env and file descriptors bp::context ctx; ctx.environment = bp::self::get_environment(); ctx.stderr_behavior = bp::redirect_stream_to_stdout(); ctx.stdout_behavior = bp::capture_stream(); --snip--

But I've seen the same problem with other configurations, including when both stderr and stdout are being captured to their own streams, and when stdout is being inherited from the parent process.

Looks like we're using boost.process 0.31, with some mods and fixes we implemented but have not yet given back (no changes to stdout or stderr capturing, though). We're building with Xcode 3.2.2 and gcc 4.0. We're running under Mac OS X 10.6.4.

Any ideas as to what's wrong and how to fix or work around it?

Best, -- Allen Cronce