From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: lidongyan <502024330056@smail.nju.edu.cn>,
Alex via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Alex <alexguo1023@gmail.com>,
jinyaoguo <guo846@purdue.edu>
Subject: Re: [PATCH] Allocate msg only after fatal checks to avoid leaks
Date: Sat, 14 Jun 2025 17:45:45 -0700 [thread overview]
Message-ID: <xmqqh60h6ddy.fsf@gitster.g> (raw)
In-Reply-To: <20250614230158.GA2568638@coredump.intra.peff.net> (Jeff King's message of "Sat, 14 Jun 2025 19:01:58 -0400")
Jeff King <peff@peff.net> writes:
> And while it may be tempting to say "well, it does not hurt to free them
> on the die() path", in my opinion that way madness lies. You may have
> access to some local variables that can be freed, but there will be many
> other heap allocations that you don't even know about! Here's a toy
> example from a similar discussion a few years ago:
>
> https://lore.kernel.org/git/YNypPeoZTRiOxPPQ@coredump.intra.peff.net/
Yeah, I recall that discussion and the example. Yes, we should not
have to crawl up from a direct caller of die() and free everything
these stack frames hold.
> I.e., this:
>
> diff --git a/builtin/notes.c b/builtin/notes.c
> index cc1163242f..f3d5eda104 100644
> --- a/builtin/notes.c
> +++ b/builtin/notes.c
> @@ -321,12 +321,8 @@ static int parse_reuse_arg(const struct option *opt, const char *arg, int unset)
> die(_("failed to resolve '%s' as a valid ref."), arg);
> if (!(value = odb_read_object(the_repository->objects, &object, &type, &len)))
> die(_("failed to read object '%s'."), arg);
> - if (type != OBJ_BLOB) {
> - strbuf_release(&msg->buf);
> - free(value);
> - free(msg);
> + if (type != OBJ_BLOB)
> die(_("cannot read note data from non-blob object '%s'."), arg);
> - }
Much nicer.
prev parent reply other threads:[~2025-06-15 0:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 19:32 [PATCH] Allocate msg only after fatal checks to avoid leaks Alex via GitGitGadget
2025-06-13 20:37 ` Junio C Hamano
2025-06-14 8:26 ` lidongyan
2025-06-14 15:40 ` Junio C Hamano
2025-06-14 15:50 ` lidongyan
2025-06-14 23:01 ` Jeff King
2025-06-15 0:45 ` Junio C Hamano [this message]
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=xmqqh60h6ddy.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=502024330056@smail.nju.edu.cn \
--cc=alexguo1023@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=guo846@purdue.edu \
--cc=peff@peff.net \
/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.