All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Elijah Newren <newren@gmail.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Martin Ågren" <martin.agren@gmail.com>,
	"Andrzej Hunt" <ajrhunt@google.com>, "Jeff King" <peff@peff.net>
Subject: Re: [PATCH 02/10] merge-recursive.c: call a new unpack_trees_options_init() function
Date: Mon, 04 Oct 2021 16:41:00 +0200	[thread overview]
Message-ID: <87y278n8tt.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CABPp-BFYxWXZQXvDSrM1Y1ZaQ1d2TENQDvx1cyawvrDO1OvExA@mail.gmail.com>


On Mon, Oct 04 2021, Elijah Newren wrote:

> On Sun, Oct 3, 2021 at 5:46 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>>
>> In the preceding commit we introduced a new UNPACK_TREES_OPTIONS_INIT
>> macro, but "merge-recursive.c" could not be converted to it since
>> it (re-)initializes a "struct unpack_trees_options" on the heap.
>>
>> In order to convert use the macro as the source of truth for
>> initialization we need to not only convert the initialization in
>> unpack_trees_start(), but also call the new
>> unpack_trees_options_init() just after the CALLOC_ARRAY() in
>> merge_start().
>
> Um...why?

Replied below.

>> When we call merge_trees() we'll call merge_start() followed by
>> merge_trees_internal(), and it will call unpack_trees_start() before
>> it does much of anything. So it's covered by an initialization in
>> unpack_trees_start().
>>
>> But when merge_recursive() is called it will call merge_start()
>> followed by merge_recursive_internal(), which won't call
>> unpack_trees_start() until its own call call to
>> merge_trees_internal(), but in the meantime it might end up using that
>> calloc'd "struct unpack_trees_options".
>
> Nothing in merge-recursive.c usings unpack_opts before
> unpack_trees_start() or after unpack_trees_finish().  If anyone
> attempts to use it elsewhere, that would itself be a bug.  So, I'd
> replace the above three paragraphs with:
>
> "Change the initialization of opt->priv_unpack_opts from using memset
> to 0, with unpack_trees_options_init()."
>
> or something like that, and then drop your change to merge_start().

Sure, I'll defer to you about being confident about that. I didn't want
to leave a copy if it hanging without the proper initialization in case
there were new callers.

>> This was OK before, as setup_unpack_trees_porcelain() would call
>> strvec_init(), and our "struct dir_struct" in turn is OK with being
>> NULL'd. Let's convert the former to macro initialization, we'll deal
>> with the latter in a subsequent commit.
>
> This is quite confusing; it's really hard to understand how this
> relates to the rest of the commit message.  I have to read the code to
> see what you're doing, and then write my own commit message in my head
> because the wording in this paragraph still doesn't parse.
>
> I'd make the change strvec_init/STRVEC_INIT changes be a separate
> patch.  I suspect it'll be easier to write the commit message for it
> as a standalone commit as well.

Sure, FWIW I had it split up locally, and figured it would be easier to
explain if the API usage change came with the initialization change that
made it possible.

>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>  merge-recursive.c | 3 ++-
>>  unpack-trees.c    | 8 ++++++--
>>  unpack-trees.h    | 5 ++++-
>>  3 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/merge-recursive.c b/merge-recursive.c
>> index e594d4c3fa1..d24a4903f1d 100644
>> --- a/merge-recursive.c
>> +++ b/merge-recursive.c
>> @@ -405,7 +405,7 @@ static int unpack_trees_start(struct merge_options *opt,
>>         struct tree_desc t[3];
>>         struct index_state tmp_index = { NULL };
>>
>> -       memset(&opt->priv->unpack_opts, 0, sizeof(opt->priv->unpack_opts));
>> +       unpack_trees_options_init(&opt->priv->unpack_opts);
>>         if (opt->priv->call_depth)
>>                 opt->priv->unpack_opts.index_only = 1;
>>         else
>> @@ -3704,6 +3704,7 @@ static int merge_start(struct merge_options *opt, struct tree *head)
>>
>>         CALLOC_ARRAY(opt->priv, 1);
>>         string_list_init_dup(&opt->priv->df_conflict_file_set);
>> +       unpack_trees_options_init(&opt->priv->unpack_opts);
>
> Drop this hunk.

Speaking of splitting things up in more understandable ways: If we're
going to hard rely on the interaction between merge_start() and
unpack_trees_start() wouldn't it make sense to lead with a change that
dropped that memset, which if this invariant holds is also redundant to
the CALLOC() of opt->priv in merge_start() in the pre-image.

  reply	other threads:[~2021-10-04 14:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04  0:46 [PATCH 00/10] unpack-trees & dir APIs: fix memory leaks Ævar Arnfjörð Bjarmason
2021-10-04  0:46 ` [PATCH 01/10] unpack-trees.[ch]: define and use a UNPACK_TREES_OPTIONS_INIT Ævar Arnfjörð Bjarmason
2021-10-04  0:46 ` [PATCH 02/10] merge-recursive.c: call a new unpack_trees_options_init() function Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04 14:41     ` Ævar Arnfjörð Bjarmason [this message]
2021-10-04 15:04       ` Elijah Newren
2021-10-04  0:46 ` [PATCH 03/10] unpack-trees.[ch]: embed "dir" in "struct unpack_trees_options" Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04  0:46 ` [PATCH 04/10] unpack-trees API: don't have clear_unpack_trees_porcelain() reset Ævar Arnfjörð Bjarmason
2021-10-04  9:31   ` Phillip Wood
2021-10-04 11:12     ` Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04 15:20     ` Ævar Arnfjörð Bjarmason
2021-10-04 16:28       ` Elijah Newren
2021-10-04  0:46 ` [PATCH 05/10] dir.[ch]: make DIR_INIT mandatory Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04  0:46 ` [PATCH 06/10] dir.c: get rid of lazy initialization Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04  0:46 ` [PATCH 07/10] unpack-trees API: rename clear_unpack_trees_porcelain() Ævar Arnfjörð Bjarmason
2021-10-04  9:38   ` Phillip Wood
2021-10-04 11:10     ` Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04  0:46 ` [PATCH 08/10] unpack-trees: don't leak memory in verify_clean_subdirectory() Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04  0:46 ` [PATCH 09/10] merge.c: avoid duplicate unpack_trees_options_release() code Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04 14:50     ` Ævar Arnfjörð Bjarmason
2021-10-04  0:46 ` [PATCH 10/10] built-ins: plug memory leaks with unpack_trees_options_release() Ævar Arnfjörð Bjarmason
2021-10-04 13:45   ` Elijah Newren
2021-10-04 14:54     ` Ævar Arnfjörð Bjarmason
2021-10-04 13:45 ` [PATCH 00/10] unpack-trees & dir APIs: fix memory leaks Elijah Newren

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=87y278n8tt.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=ajrhunt@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.agren@gmail.com \
    --cc=newren@gmail.com \
    --cc=pclouds@gmail.com \
    --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.