Re: [PATCH] Fix start_command() pipe bug when stdin is closed.

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Aug 25, 2008, 10:44 UTC
Message-ID: <48B28CF8.2060306@viscovery.net>
In-Reply-To: <quack.20080825T0128.lthr68djy70@roar.cs.berkeley.edu>

Karl Chen schrieb:

Show 6 quoted lines

> I ran into what I think is a bug:
>     sh$ git fetch 0<&-
> 
> (i.e. run git-fetch with stdin closed.)
> It aborts with:
>     fatal: read error (Bad file descriptor)

When I try these instructions I don't get an error; instead the command runs successfully.

Show 10 quoted lines

> I think the problem arises from the use of dup2+close in
> start_command().  It wants to rename a pipe file descriptor to 0,
> so it does
>     dup2(from, to);
>     close(from);
> 
> ... but in this case from == to == 0, so 
>     dup2(0, 0);
>     close(0);
> just ends up closing the pipe.

While I do see that there is a problem, it is only half of the story, and your patch addresses only this half.

What if stdout is closed, too? Then the ends of the first allocated pipe would go to fds 0 and 1, and then the pipe end at 1 would be closed by a subsequent dup2(xxx, 1).

Junio, what's your take on this?

-- Hannes