From: Junio C Hamano <gitster@pobox•com>
To: Stefan Beller <sbeller@google•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 01/15] read-cache: fix memleak
Date: Fri, 20 Mar 2015 20:26:14 -0700 [thread overview]
Message-ID: <xmqq619vc9pl.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1426897692-18322-2-git-send-email-sbeller@google.com> (Stefan Beller's message of "Fri, 20 Mar 2015 17:27:58 -0700")
Stefan Beller <sbeller@google•com> writes:
> `ce` is allocated in make_cache_entry and should be freed if it is not
> used any more. refresh_cache_entry as a wrapper around refresh_cache_ent
> will either return `ce` or a new updated cache entry which is allocated
> to new memory. In that case we need to free `ce` ourselfs.
>
> Signed-off-by: Stefan Beller <sbeller@google•com>
> ---
> read-cache.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/read-cache.c b/read-cache.c
> index 8d71860..f72ea9f 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -747,6 +747,8 @@ struct cache_entry *make_cache_entry(unsigned int mode,
> free(ce);
> return NULL;
> } else {
> + if (ret != ce)
> + free(ce);
> return ret;
> }
> }
Good, I vaguely recall that we did something similar in another
codepath that forgot the fact that refresh_cache_entry() may make
the incoming ce unnecessary.
As the rule is "if ret is different from ce, then ce must be freed"
in this codepath, I wonder if this is easier to read:
ret = refresh_cache_entry(ce, ...);
if (ret != ce)
free(ce);
return ret;
next prev parent reply other threads:[~2015-03-21 3:26 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 [this message]
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
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=xmqq619vc9pl.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--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