threads / patch / 10920

patchFix start_command closing cmd->out/in regardless of cmd->close_out/in

Subject: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in

## tl;dr

4 messages between Nov 18, 2007 and Nov 19, 2007. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Ping Yin· Nov 18, 2007, 17:36 UTC · lore
When 'FILE *fp' is assigned to child_process.out and then start_command or
run_command is run, the standard output of the child process is expected to
be outputed to fp. However, sometimes fp is not expected to be closed since
further IO may be still performmed on fp.
---
 run-command.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)
Show changes to run-command.c +0 −4
diff --git a/run-command.c b/run-command.c
index 476d00c..4e5f58d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
 
 	if (need_in)
 		close(fdin[0]);
-	else if (cmd->in)
-		close(cmd->in);
 
 	if (need_out)
 		close(fdout[1]);
-	else if (cmd->out > 1)
-		close(cmd->out);
 
 	if (need_err)
 		close(fderr[1]);
-- 
1.5.3.5.1876.g7ba19-dirty
Junio C Hamano· Nov 18, 2007, 18:52 UTC · re: Ping Yin · lore

Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in

Ping Yin <pkufranky@gmail.com> writes:
> When 'FILE *fp' is assigned to child_process.out and then start_command or
> run_command is run, the standard output of the child process is expected to
> be outputed to fp. However, sometimes fp is not expected to be closed since
> further IO may be still performmed on fp.

Could you clarify "However, sometimes" with a concrete codepath that has this problem in the proposed commit log message, and Sign-off your patch please?

Johannes Sixt· Nov 19, 2007, 07:39 UTC · re: Ping Yin · lore

Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in

Ping Yin schrieb:
Show 26 quoted lines
> When 'FILE *fp' is assigned to child_process.out and then start_command or
> run_command is run, the standard output of the child process is expected to
> be outputed to fp. However, sometimes fp is not expected to be closed since
> further IO may be still performmed on fp.
> ---
>  run-command.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/run-command.c b/run-command.c
> index 476d00c..4e5f58d 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
>  
>  	if (need_in)
>  		close(fdin[0]);
> -	else if (cmd->in)
> -		close(cmd->in);
>  
>  	if (need_out)
>  		close(fdout[1]);
> -	else if (cmd->out > 1)
> -		close(cmd->out);
>  
>  	if (need_err)
>  		close(fderr[1]);

This is dangerous! You have to audit all current callers whether they close cmd->in or cmd->out (if they don't need the fd anymore). Otherwise you risk to keep a writable pipe end open and then the reader hangs, waiting for input that will never arrive.

-- Hannes
Junio C Hamano· Nov 19, 2007, 08:46 UTC · re: Johannes Sixt · lore

Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in

Johannes Sixt <j.sixt@viscovery.net> writes:
Show 28 quoted lines
> Ping Yin schrieb:
>> When 'FILE *fp' is assigned to child_process.out and then start_command or
>> run_command is run, the standard output of the child process is expected to
>> be outputed to fp. However, sometimes fp is not expected to be closed since
>> further IO may be still performmed on fp.
>> ---
>>  run-command.c |    4 ----
>>  1 files changed, 0 insertions(+), 4 deletions(-)
>>
>> diff --git a/run-command.c b/run-command.c
>> index 476d00c..4e5f58d 100644
>> --- a/run-command.c
>> +++ b/run-command.c
>> @@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
>>   	if (need_in)
>>  		close(fdin[0]);
>> -	else if (cmd->in)
>> -		close(cmd->in);
>>   	if (need_out)
>>  		close(fdout[1]);
>> -	else if (cmd->out > 1)
>> -		close(cmd->out);
>>   	if (need_err)
>>  		close(fderr[1]);
>
> This is dangerous! You have to audit all current callers whether they
> close cmd->in or cmd->out (if they don't need the fd
> anymore).

I am reasonably sure that they are already relying on these auto closing of the file descriptors.

Funny that somebody falls into the trap the day after we discussed it on another thread.

← back to recent threads