t0008 hang on streaming test (OS X)

The newest test in t0008 "streaming support for --stdin", seems to hang sporadically on my MacBook Pro (running 10.8.4).  The hang seems to be related to running it in parallel with other tests, as I can only reliably cause it by running with prove  and -j 3.  However, once that has hung I am able to semi-reliably have it occur by running the test separately (with the test hung in the background, using separate trash directories via the --root option).

Experimentation has led me to find that it is hanging when trying to read the 2nd response from check-ignore.

I am somewhat stuck on how to fix it.  Any ideas?

~~ Brian Gernhardt

On Wed, Jul 10, 2013 at 6:36 PM, Brian Gernhardt
[off-list ref] wrote:

I am somewhat stuck on how to fix it.  Any ideas?

I don't have anything to reproduce here, but usually I start
investigating this kind of problems by attaching the hung process with
gdb to see the current state (if it's stuck in a specific state), or
to investigate the end-less loop.
That usually help finding a good starting point.

Cheers,
Antoine

On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:

The newest test in t0008 "streaming support for --stdin", seems to
hang sporadically on my MacBook Pro (running 10.8.4).  The hang seems
to be related to running it in parallel with other tests, as I can
only reliably cause it by running with prove  and -j 3.  However, once
that has hung I am able to semi-reliably have it occur by running the
test separately (with the test hung in the background, using separate
trash directories via the --root option).

I can't replicate the hang here (on Linux) doing:

  for i in `seq 1 30`; do
      ./t0008-ignores.sh --root=/tmp/foo/$i &
  done

Do you know which test it is hanging on? You mentioned that you can
replicate it outside of "prove"; what does running with "-v" say?

The last test in t0008, with the fifos, would make me the most
suspicious. The way we do it _should_ be fine, but I'm wondering if the
shell is blocking in exec here:

  mkfifo in out &&
  (git check-ignore -n -v --stdin <in >out &) &&
  exec 9>in &&

That is, if the fifo is not opened for some reason by the backgrounded
process (there's a race, of course, but the outer shell should just
block until the sub-shell actually opens it). I wonder if the
descriptor-opening behavior of:

  cmd <in >out &

is different between shells (that is, if it backgrounds the opening of
in and out on some shells, but not on others). But then I would expect
it to fail consistently.

Just for fun, does switching the middle line there to:

  (sh -c "git check-ignore -n -v --stdin <in >out" &) &&

have any effect?

-Peff

On Jul 11, 2013, at 9:34 AM, Jeff King [off-list ref] wrote:

On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:

quoted

The newest test in t0008 "streaming support for --stdin",

quoted

Experimentation has led me to find that it is hanging when trying to read the 2nd response from check-ignore.

Do you know which test it is hanging on? You mentioned that you can
replicate it outside of "prove"; what does running with "-v" say?

The last test in t0008, with the fifos, would make me the most
suspicious.

The 2nd `read response <out` line is where it was hanging, based on a variety of echos added to the test.

~~ Brian

On Jul 10, 2013, at 4:35 PM, Antoine Pelisse [off-list ref] wrote:

On Wed, Jul 10, 2013 at 6:36 PM, Brian Gernhardt
[off-list ref] wrote:

quoted

I am somewhat stuck on how to fix it.  Any ideas?

I don't have anything to reproduce here, but usually I start
investigating this kind of problems by attaching the hung process with
gdb to see the current state (if it's stuck in a specific state), or
to investigate the end-less loop.
That usually help finding a good starting point.

Unfortunately, the hung process is /bin/sh (aka bash).  Using the "Sample" function of Activity Monitor gave me that 100% of the time was spent in libc's _open...  Which enlightens me not at all.

~~ Brian Gernhardt