From: Junio C Hamano <gitster@pobox•com>
To: Stefan Beller <sbeller@google•com>
Cc: git@vger•kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail•com>
Subject: Re: [PATCH 10/15] commit.c: fix a memory leak
Date: Fri, 20 Mar 2015 20:59:18 -0700 [thread overview]
Message-ID: <xmqqk2ybatm1.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1426897692-18322-11-git-send-email-sbeller@google.com> (Stefan Beller's message of "Fri, 20 Mar 2015 17:28:07 -0700")
Stefan Beller <sbeller@google•com> writes:
> Signed-off-by: Stefan Beller <sbeller@google•com>
> ---
> builtin/commit.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 961e467..da79ac4 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -229,7 +229,7 @@ static int commit_index_files(void)
> static int list_paths(struct string_list *list, const char *with_tree,
> const char *prefix, const struct pathspec *pattern)
> {
> - int i;
> + int i, ret;
> char *m;
>
> if (!pattern->nr)
> @@ -256,7 +256,9 @@ static int list_paths(struct string_list *list, const char *with_tree,
> item->util = item; /* better a valid pointer than a fake one */
> }
>
> - return report_path_error(m, pattern, prefix);
> + ret = report_path_error(m, pattern, prefix);
> + free(m);
> + return ret;
> }
Looks correct.
A tangent. We may want to move report_path_error() to somewhere
more "common"-ish, like dir.c which is where we have bulk of
pathspec matching infrastructure. Seeing the function used from
builtin/ls-files.c makes me feel dirty.
A further tangent (Duy Cc'ed for this point). We might want to
rethink the interface to ce_path_match() and report_path_error()
so that we do not have to do a separate allocation of "has this
pathspec been used?" array. This was a remnant from the olden days
back when pathspec were mere "const char **" where we did not have
any room to add per-item bit---these days pathspec is repreasented
as an array of "struct pathspec" and we can afford to add a bit
to the structure---which will make this kind of leak much less
likely to happen.
next prev parent reply other threads:[~2015-03-21 4:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-21 0:27 [PATCH 00/15] Fixing memory leaks Stefan Beller
2015-03-21 0:27 ` [PATCH 01/15] read-cache: fix memleak Stefan Beller
2015-03-21 3:26 ` Junio C Hamano
2015-03-23 16:24 ` Stefan Beller
2015-03-23 17:57 ` [PATCH 1/2] " Stefan Beller
2015-03-23 17:57 ` [PATCH 2/2] read-cache.c: fix a memleak in add_to_index Stefan Beller
2015-03-23 18:07 ` Junio C Hamano
2015-03-23 18:11 ` [PATCH 1/2] read-cache: fix memleak Junio C Hamano
2015-03-21 0:27 ` [PATCH 02/15] read-cache: Improve readability Stefan Beller
2015-03-21 4:19 ` Junio C Hamano
2015-03-21 5:11 ` Stefan Beller
2015-03-22 19:26 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 03/15] read-cache: free cache entry in add_to_index in case of early return Stefan Beller
2015-03-21 3:31 ` Junio C Hamano
2015-03-21 5:10 ` Stefan Beller
2015-03-22 19:11 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 04/15] update-index: fix a memleak Stefan Beller
2015-03-21 3:40 ` Junio C Hamano
2015-03-23 16:53 ` [PATCH] update-index: Don't copy memory around Stefan Beller
2015-03-23 17:11 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 05/15] builtin/apply.c: fix a memleak Stefan Beller
2015-03-21 3:45 ` Junio C Hamano
2015-03-23 17:13 ` [PATCH] builtin/apply.c: fix a memleak (Fixup, squashable) Stefan Beller
2015-03-23 17:27 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 06/15] merge-blobs.c: Fix a memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 07/15] merge-recursive: fix memleaks Stefan Beller
2015-03-21 3:48 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 08/15] http-push: Remove unneeded cleanup Stefan Beller
2015-03-21 0:28 ` [PATCH 09/15] http: release the memory of a http pack request as well Stefan Beller
2015-03-22 19:36 ` Junio C Hamano
2015-03-24 16:54 ` Stefan Beller
2015-03-24 17:48 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 10/15] commit.c: fix a memory leak Stefan Beller
2015-03-21 3:59 ` Junio C Hamano [this message]
2015-03-24 13:42 ` Duy Nguyen
2015-03-24 21:17 ` Re* " Junio C Hamano
2015-03-24 21:20 ` Stefan Beller
2015-03-21 0:28 ` [PATCH 11/15] builtin/check-attr: fix a memleak Stefan Beller
2015-03-21 4:02 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 12/15] builtin/merge-base: fix memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 13/15] builtin/unpack-file: fix a memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 14/15] builtin/cat-file: free memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 15/15] ls-files: fix a memleak Stefan Beller
2015-03-21 3:21 ` [PATCH 00/15] Fixing memory leaks 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=xmqqk2ybatm1.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=pclouds@gmail$(echo .)com \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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