git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Martín Nieto" <cmn@elego.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] setup_path(): Free temporary buffer
Date: Mon, 14 Mar 2011 23:01:53 +0100	[thread overview]
Message-ID: <1300140119.4320.38.camel@bee.lab.cmartin.tk> (raw)
In-Reply-To: <7v7hc1cvdt.fsf@alter.siamese.dyndns.org>

On lun, 2011-03-14 at 13:14 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
> [...]
> 
>     Update only one caller setup_path() to follow the new API, but leave
>     other callers to leak even in normal cases.  The caller in git.c exits
>     immediately after using it, so we don't care about the leak there
>     anyway.  Also help.c has a few calls to it but the number of calls to
>     the function is small and bounded, so the leak is small and we don't
>     care.

 Oops. I blindly tested the path only on the test case where it was
triggering an error without it and completely missed the other uses,
which is embarrassing.

> 
> 
> And then reviewers can agree or disagree if the small leaks in git.c (just
> one string allocation that immediately is followed by exit after its use)
> and help.c (in list_commands() and load_commands_list(), neither of which
> is called millions of times anyway) are OK to accept.
> 
> I tend to think they are Ok, but then I also tend to think one leak of
> exec-path return value in setup_path() is perfectly fine for the same
> reason, so in that sense I don't see a point in this patch...

 Which brings us to the matter of whether we actually care about memory
leaks, as the processes are short-lived and the system is going to clean
up after us. Do we, unless the leaks are huge? As there is built-in
valgrind support in the test suite, I went in with the assumption that
we did. It seems however that hardly any code paths free their memory,
other than when using strbuf.

 In case we don't, valgrind should be told not to bother reporting leaks
(and maybe mention in some document that small leaks are not an issue).

> 
> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 38545e8..c16c3d4 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -73,11 +73,11 @@ const char *git_exec_path(void)
> >  	const char *env;
> >  
> >  	if (argv_exec_path)
> > -		return argv_exec_path;
> > +		return xstrdup(argv_exec_path);
> >  
> >  	env = getenv(EXEC_PATH_ENVIRONMENT);
> >  	if (env && *env) {
> > -		return env;
> > +		return xstrdup(env);
> >  	}
> >  
> >  	return system_path(GIT_EXEC_PATH);
> > @@ -99,10 +99,13 @@ void setup_path(void)
> >  {
> >  	const char *old_path = getenv("PATH");
> >  	struct strbuf new_path = STRBUF_INIT;
> > +	char *exec_path = (char *) git_exec_path();
> >  
> > -	add_path(&new_path, git_exec_path());
> > +	add_path(&new_path, exec_path);
> >  	add_path(&new_path, argv0_path);
> >  
> > +	free(exec_path);
> > +
> >  	if (old_path)
> >  		strbuf_addstr(&new_path, old_path);
> >  	else

  reply	other threads:[~2011-03-14 22:11 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14 19:18 [PATCH 0/3] Fix some errors reported by valgrind Carlos Martín Nieto
2011-03-14 19:18 ` [PATCH 1/3] make_absolute_path: Don't try to copy a string to itself Carlos Martín Nieto
2011-03-14 20:02   ` Jeff King
2011-03-14 20:25   ` Junio C Hamano
2011-03-14 22:02     ` Carlos Martín Nieto
2011-03-14 22:58       ` Junio C Hamano
2011-03-15 11:59         ` Carlos Martín Nieto
2011-03-15 12:40           ` Carlos Martín Nieto
2011-03-15 17:02             ` Junio C Hamano
2011-03-15 17:27               ` Carlos Martín Nieto
2011-03-16 14:16                 ` Nguyen Thai Ngoc Duy
2011-03-16 14:49                   ` Carlos Martín Nieto
2011-03-16 14:58                     ` Nguyen Thai Ngoc Duy
2011-03-16 14:04               ` Nguyen Thai Ngoc Duy
2011-03-16 15:08                 ` Carlos Martín Nieto
2011-03-14 19:18 ` [PATCH 2/3] setup_path(): Free temporary buffer Carlos Martín Nieto
2011-03-14 20:09   ` Jeff King
2011-03-14 22:18     ` Carlos Martín Nieto
2011-03-16 11:26     ` [PATCH] system_path: use a static buffer Carlos Martín Nieto
2011-03-16 15:58       ` Erik Faye-Lund
2011-03-16 16:24         ` Carlos Martín Nieto
2011-03-16 16:33         ` Carlos Martín Nieto
2011-03-16 20:43           ` Junio C Hamano
2011-03-17 11:01             ` Carlos Martín Nieto
2011-03-17 14:24               ` Carlos Martín Nieto
2011-03-18  7:25                 ` Junio C Hamano
2011-03-21  9:56                   ` Carlos Martín Nieto
2011-03-21 11:14                     ` Jeff King
2011-03-21 15:26                       ` Carlos Martín Nieto
2011-03-21 15:51                         ` Jeff King
2011-03-21 15:57                           ` Carlos Martín Nieto
2011-03-18 10:34                 ` Nguyen Thai Ngoc Duy
2011-03-18 11:38                   ` PATH_MAX (Re: [PATCH] system_path: use a static buffer) Jonathan Nieder
2011-03-18 11:54                     ` Nguyen Thai Ngoc Duy
2011-03-21  9:47                     ` Carlos Martín Nieto
2011-03-21 12:37                       ` Lasse Makholm
2011-03-21 11:19                     ` Nguyen Thai Ngoc Duy
2011-03-18 11:39                   ` [PATCH 1/2] wrapper.c: add xgetcwd() Nguyễn Thái Ngọc Duy
2011-03-18 11:39                     ` [PATCH 2/2] setup_gently: use xgetcwd() Nguyễn Thái Ngọc Duy
2011-03-14 20:14   ` [PATCH 2/3] setup_path(): Free temporary buffer Junio C Hamano
2011-03-14 22:01     ` Carlos Martín Nieto [this message]
2011-03-15  1:12       ` Jeff King
2011-03-15  9:32         ` [PATCH] t/README: Add a note about running commands under valgrind Carlos Martín Nieto
2011-03-15 17:06           ` Junio C Hamano
2011-03-15 17:08             ` Carlos Martín Nieto
2011-03-14 19:18 ` [PATCH 3/3] clone: Free a few paths Carlos Martín Nieto
2011-03-14 19:45   ` Jonathan Nieder
2011-03-18  7:25     ` Junio C Hamano

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=1300140119.4320.38.camel@bee.lab.cmartin.tk \
    --to=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).