Begin forwarded message:

From: "David T. Lewis" <lewis@mail.msen.com> Subject: Re: OSProcess - is process done? Date: April 25, 2012 7:47:22 PM EDT To: DeNigris Sean <sean@clipperadams.com>

On Wed, Apr 25, 2012 at 01:50:35PM -0400, DeNigris Sean wrote:

...

David, does this tell us anything? I'm *very* happy to help solve this on the Mac, since I use OSP extensively...

From: "Sean P. DeNigris [via Smalltalk]" <ml-node+s1294792n4587479h37@n4.nabble.com> Subject: Re: OSProcess - is process done? Date: April 25, 2012 1:48:18 PM EDT To: "Sean P. DeNigris" <sean@clipperadams.com>

...

p upToEnd. "This hangs, even though there is output in the pipe"

I debugged this with the Stack VM from Jenkins. It's hanging in sqFileBasicPluginPrims.c on line 360: bytesRead = fread(dst, 1, count, file);

This line seems to never return, although the docs suggest that it should just return an error or less data if the requested data is not available.

Hi Sean,

An fread() call will block when reading from a unix pipe unless the pipe end has been set to nonblocking mode (see #primSQFileSetNonBlocking:). A blocking read call like this will block the entire VM, and if you get into a condition where you are reading from a blocking pipe that has no data available, the VM and image will lock up until data is available in the pipe (which might be never). It's not likely that there would be anything wrong with the fread call itself, so there must be something going on here that gets us into a state where a read is being done on a pipe that has no data, and that has not set to nonblocking mode. Right now I can't guess what is doing that, but based on what you see in gdb it is probably that kind of situation.

In order to debug the problem, here is what I would suggest doing:

- Edit the two methods String>>withoutTrailingBlanks and String>>#withBlanksTrimed, and comment out (or delete) the #deprecated:on: lines in these two methods. This will allow you to run the unit tests for OSProcess/CommandShell. Do not just turn off the deprecation warning preferences, this does not work.

- Load the latest versions of both OSProcess and CommandShell from SqueakSource. Load the full CommandShell package, and ignore the warnings about two MVC classes. I made some minor updates to these packages yesterday to support Pharo, so it's best if you can use the latest versions.

- Open a test runner and run CommandShellTestCase. These will exercise PipeableOSProcess (note that the PipeableOSProcessTestCase tests will fail on Cog, so do not worry about those for now). I find that CommandShellTestCase tests are all green for Pharo running on Cog using the latest Linux Cog VM from Eliot's site. There may be differences on OS X (e.g. paths to commands), but it will be easy to figure out if that is happening. Hopefully you will get all green tests, or just some explainable failures related to OS X differences.

If the above works for you on a Mac, then we will know that basic PipeableOSProcess functionality is working and we must have some kind of problem in the way it is being used on OS X, or maybe what you are doing is exposing a bug that is not covered by the unit tests. On the other hand, if the CommandShellTestCase tests fail, that should lead us to some other kind of problem.

Dave