git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCHv3 4/4] clone: use free_refspec() to free refspec list
Date: Mon, 15 May 2017 19:10:10 -0400	[thread overview]
Message-ID: <20170515231009.2tvukcbmfywnqlaw@sigill.intra.peff.net> (raw)
In-Reply-To: <CAM0VKjkr+EBEErQZxW-prrcdAyF4D-icU_ao9vvO3yJ1HWhmhw@mail.gmail.com>

On Mon, May 15, 2017 at 01:29:07PM +0200, SZEDER Gábor wrote:

> On Mon, May 15, 2017 at 1:05 PM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> > From: Jeff King <peff@peff.net>
> >
> > Using free() on a refspec was always leaky, as its string
> > fields also need freed. But it became more so when ad00f128d
> > (clone: respect configured fetch respecs during initial
> > fetch, 2016-03-30) taught clone to create a list of
> > refspecs, each of which need to be freed.
> >
> > [sg: adjusted the function parameters.]
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> > ---
> >  builtin/clone.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/builtin/clone.c b/builtin/clone.c
> > index 4144190da..4bf28d7f5 100644
> > --- a/builtin/clone.c
> > +++ b/builtin/clone.c
> > @@ -1120,6 +1120,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> >         strbuf_release(&value);
> >         junk_mode = JUNK_LEAVE_ALL;
> >
> > -       free(refspec);
> > +       free_refspec(remote->fetch_refspec_nr + 1, remote->fetch);
> >         return err;
> >  }
> 
> Erm...  I should have given a bit more thought to this last patch,
> shouldn't I?
> 
> First, the unchanged commit message is now (i.e. by using the parsed
> refspecs returned by remote_get()) completely outdated.
> Second, while it properly frees those refspecs, i.e. the array and all
> its string fields, it will now leak the memory pointed by the
> 'refspec' variable.  However, why free just that one field of the
> 'struct *remote'?  Alas, we don't seem to have a free_remote()
> function...

Right, the "struct remote" fields are meant to last the program
lifetime, and just go away when the program does. So they are never
freed. We could just lump this in with them, and remove the free()
entirely.

It's a little funny with your patch as-is, because "struct remote"
doesn't actually know about the refspec we stuck on the end. But since
it doesn't free its refspecs anyway, it's not any more leaky than all
the other entries.

-Peff

  reply	other threads:[~2017-05-15 23:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 11:05 [PATCHv3 0/4] clone: respect configured fetch respecs during initial fetch SZEDER Gábor
2017-05-15 11:05 ` [PATCHv3 1/4] clone: respect additional configured fetch refspecs " SZEDER Gábor
2017-05-15 23:07   ` Jeff King
2017-05-26 10:04     ` SZEDER Gábor
2017-05-26 13:30       ` Jeff King
2017-05-30  3:53         ` Junio C Hamano
2017-05-30  3:55           ` Jeff King
2017-05-30  7:11           ` SZEDER Gábor
2017-05-30  7:12             ` [PATCHv4 1/2] " SZEDER Gábor
2017-05-30  7:12               ` [PATCHv4 2/2] Documentation/clone: document ignored configuration variables SZEDER Gábor
2017-05-30  9:01                 ` Ævar Arnfjörð Bjarmason
2017-05-31  8:50                   ` SZEDER Gábor
2017-05-31 14:17                     ` Ævar Arnfjörð Bjarmason
2017-06-13 23:24                 ` Jonathan Nieder
2017-05-31  4:23               ` [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch Jeff King
2017-05-31  9:34                 ` SZEDER Gábor
2017-06-05  8:18                   ` Jeff King
2017-06-06 18:19                     ` SZEDER Gábor
2017-06-06 18:37                       ` Jeff King
2017-06-07 11:17                         ` SZEDER Gábor
2017-06-14  0:48               ` Jonathan Nieder
2017-06-14  9:50                 ` Jeff King
2017-06-16 17:36                 ` SZEDER Gábor
2017-06-16 17:38                   ` [PATCHv5 0/2] " SZEDER Gábor
2017-06-16 17:38                     ` [PATCHv5 1/2] " SZEDER Gábor
2017-06-16 20:37                       ` Jonathan Nieder
2017-06-17 11:22                       ` Jeff King
2017-06-22 22:23                         ` Junio C Hamano
2017-08-12  0:48                           ` Junio C Hamano
2017-06-16 17:38                     ` [PATCHv5 2/2] Documentation/clone: document ignored configuration variables SZEDER Gábor
2017-06-16 18:23                       ` Ævar Arnfjörð Bjarmason
2017-06-16 20:41                         ` Jonathan Nieder
2017-06-16 21:10                           ` Ævar Arnfjörð Bjarmason
2017-06-16 22:15                             ` SZEDER Gábor
2017-06-16 20:38                       ` Jonathan Nieder
2017-06-16 22:09                       ` Junio C Hamano
2017-05-31  4:27             ` [PATCH] remote: drop free_refspecs() function Jeff King
2017-06-14  0:49               ` Jonathan Nieder
2017-05-15 11:05 ` [PATCHv3 2/4] Documentation/clone: document ignored configuration variables SZEDER Gábor
2017-05-26 14:01   ` SZEDER Gábor
2017-05-15 11:05 ` [PATCHv3 3/4] remote: drop free_refspecs() function SZEDER Gábor
2017-05-15 11:05 ` [PATCHv3 4/4] clone: use free_refspec() to free refspec list SZEDER Gábor
2017-05-15 11:29   ` SZEDER Gábor
2017-05-15 23:10     ` Jeff King [this message]
2017-05-23  7:38     ` Junio C Hamano
2017-05-23 11:27       ` Jeff King
2017-05-23 12:06       ` SZEDER Gábor
2017-05-15 22:46 ` [PATCHv3 0/4] clone: respect configured fetch respecs during initial fetch Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20170515231009.2tvukcbmfywnqlaw@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=szeder.dev@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).