All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git list <git@vger.kernel.org>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH] transport-helper.c: don't leak fdopen'd stream buffers
Date: Sun, 13 Sep 2009 09:45:10 +0200	[thread overview]
Message-ID: <878wgjz3sp.fsf@meyering.net> (raw)
In-Reply-To: <7vtyz760lm.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Sat, 12 Sep 2009 19:27:01 -0700")

Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> diff --git a/transport-helper.c b/transport-helper.c
>> index f57e84c..0bbd014 100644
>> --- a/transport-helper.c
>> +++ b/transport-helper.c
>> @@ -49,6 +49,7 @@ static struct child_process *get_helper(struct transport *transport)
>>  		if (!strcmp(buf.buf, "fetch"))
>>  			data->fetch = 1;
>>  	}
>> +	fclose (file);
>>  	return data->helper;
>>  }
>>
>> @@ -88,6 +89,7 @@ static int fetch_with_fetch(struct transport *transport,
>>  		if (strbuf_getline(&buf, file, '\n') == EOF)
>>  			exit(128); /* child died, message supplied already */
>>  	}
>> +	fclose (file);
>>  	return 0;
>>  }
>
> The callchain of fetch_with_fetch() looks like:
>
>     fetch_with_fetch()
>         helper = get_helper();
>         --> get_helper()
>             - start helper with start_command();
>             - read from helper->out until it sees an empty line;
>             - break out of the loop;
>         <-- return helper
>         - file = xfdopen(helper->out) to get another FILE on the fd
>         - read the rest of the output from helper->out via file
>
> It seems to me that the fclose() in get_helper() will close the underlying
> fd and would break the caller, no?

I confess that my sole test was to run "make test", which passed.
If the fd must live on, a slightly less invasive change would be to
xdup each descriptor just before each of the three xfdopen calls, e.g.,

-       file = xfdopen(helper->out, "r");
+       file = xfdopen(xdup(helper->out), "r");

> I think "struct helper_data" should get a new FILE* field and once
> somebody creates a FILE* out of its helper->out, that FILE* can be passed
> around without a new xfdopen().
>
> Or something like that.

That's probably best.

> Who is responsible for closing the underlying helper->out fd in the
> start_command() API, by the way?

  reply	other threads:[~2009-09-13  7:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-12  9:38 [PATCH] transport-helper.c: don't leak fdopen'd stream buffers Jim Meyering
2009-09-13  2:27 ` Junio C Hamano
2009-09-13  7:45   ` Jim Meyering [this message]
2009-09-13 15:20   ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878wgjz3sp.fsf@meyering.net \
    --to=jim@meyering.net \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.