From: "René Scharfe" <l.s.r@web.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>, Taylor Blau <me@ttaylorr.com>,
Christian Couder <chriscool@tuxfamily.org>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH v2 3/3] Revert "pack-objects: lazily set up "struct rev_info", don't leak"
Date: Mon, 28 Nov 2022 16:56:04 +0100 [thread overview]
Message-ID: <59431916-9f55-d0f4-da54-e7369803eb4c@web.de> (raw)
In-Reply-To: <221128.865yezkule.gmgdl@evledraar.gmail.com>
Am 28.11.2022 um 15:34 schrieb Ævar Arnfjörð Bjarmason:
>
> On Mon, Nov 28 2022, René Scharfe wrote:
>
>> Am 28.11.2022 um 12:31 schrieb Ævar Arnfjörð Bjarmason:
>>>
>>> On Mon, Nov 28 2022, René Scharfe wrote:
>>>
>>>> Am 28.11.2022 um 11:03 schrieb Junio C Hamano:
>>>>> René Scharfe <l.s.r@web.de> writes:
>>>>>
>>>>>> This reverts commit 5cb28270a1ff94a0a23e67b479bbbec3bc993518.
>>>>>>
>>>>>> 5cb28270a1 (pack-objects: lazily set up "struct rev_info", don't leak,
>>>>>> 2022-03-28) avoided leaking rev_info allocations in many cases by
>>>>>> calling repo_init_revisions() only when the .filter member was actually
>>>>>> needed, but then still leaking it. That was fixed later by 2108fe4a19
>>>>>> (revisions API users: add straightforward release_revisions(),
>>>>>> 2022-04-13), making the reverted commit unnecessary.
>>>>>
>>>>> Hmph, with this merged, 'seen' breaks linux-leaks job in a strange
>>>>> way.
>>>>>
>>>>> https://github.com/git/git/actions/runs/3563546608/jobs/5986458300#step:5:3917
>>>>>
>>>>> Does anybody want to help looking into it?
>>>
>>> [I see we crossed E-Mails]:
>>> https://lore.kernel.org/git/221128.868rjvmi3l.gmgdl@evledraar.gmail.com/
>>>
>>>> The patch exposes that release_revisions() leaks the diffopt allocations
>>>> as we're yet to address the TODO added by 54c8a7c379 (revisions API: add
>>>> a TODO for diff_free(&revs->diffopt), 2022-04-14).
>>>
>>> That's correct, and we have that leak in various places in our codebase,
>>> but per the above side-thread I think this is primarily exposing that
>>> we're setting up the "struct rev_info" with your change when we don't
>>> need to. Why can't we just skip it?
>>
>> I have no idea how to stop get_object_list() from using struct rev_info.
>> We could let it take a struct list_objects_filter_options pointer
>> instead and have it build a struct rev_info internally, but that would
>> just move the problem, not solve it.
>
> I mean skip it when it's not needed, it's needed when we call
> get_object_list().
>
> But what "problem" is being caused by get_object_list()? That there's
> some other case(s) where it'll leak still? I haven't checked, I think we
> should leave that for some other time if there's such leaks, and just
> not introduce any new leaks in this topic.
The problem is "How to use struct rev_info without leaks?". No matter
where you move it, the leak will be present until the TODO in
release_revisions() is done.
>
>>> Yeah, if we do set it up we'll run into an outstanding leak, and that
>>> should also be fixed (I have some local patches...), but the other cases
>>> I know of where we'll leak that data is where we're actually using the
>>> "struct rev_info".
>>>
>>> I haven't tried tearing your change apart to poke at it myself, and
>>> maybe there's some really good reason for why you can't separate getting
>>> rid of the J.5.7 dependency and removing the lazy-init.
>>>
>>>> The patch below plugs it locally.
>>>>
>>>> --- >8 ---
>>>> Subject: [PATCH 4/3] fixup! revision: free diffopt in release_revisions()
>>>>
>>>> Signed-off-by: René Scharfe <l.s.r@web.de>
>>>> ---
>>>> builtin/pack-objects.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
>>>> index 3e74fbb0cd..a47a3f0fba 100644
>>>> --- a/builtin/pack-objects.c
>>>> +++ b/builtin/pack-objects.c
>>>> @@ -4462,6 +4462,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
>>>> } else {
>>>> get_object_list(&revs, rp.nr, rp.v);
>>>> }
>>>> + diff_free(&revs.diffopt);
>>>> release_revisions(&revs);
>>>> cleanup_preferred_base();
>>>> if (include_tag && nr_result)
>>>
>>> So, the main motivation for the change was paranoia that a compiler or
>>> platform might show up without J.5.7 support and that would bite us, but
>>> we're now adding a double-free-in-waiting?
>>>
>>> I think we're both a bit paranoid, but clearly have different
>>> paranoia-priorities :)
>>>
>>> If we do end up with some hack like this instead of fixing the
>>> underlying problem I'd much prefer that such a hack just be an UNLEAK()
>>> here.
>>>
>>> I.e. we have a destructor for "revs.*" already, let's not bypass it and
>>> start freeing things from under it, which will result in a double-free
>>> if we forget this callsite once the TODO in 54c8a7c379 is addressed.
>>
>> Well, that TODO fix should remove this new diff_free() call, but I
>> agree that this is fragile.
>>
>> Removing the "TEST_PASSES_SANITIZE_LEAK=true" line from affected tests
>> is probably better.
>
> Or just not introduce new leaks, per my suggested fix-up at
> https://lore.kernel.org/git/221128.86zgcbl0pe.gmgdl@evledraar.gmail.com/
> (which it looks like you haven't seen when this E-Mail is composed...).
Not adding leaks is a good idea. AFAICS none of my patches so far add
any. Patch 3 of v2 exposes an existing one that was only triggered by
the --filter option before. Which is also not ideal, of course, but
giving it more visibility hopefully will motivate a proper fix.
>>> As you'd see if you made release_revisions() simply call
>>> diff_free(&revs.diffopt) doing so would reveal some really gnarly edge
>>> cases.
>>
>> That was my first attempt; it breaks lots of tests due to double frees.
>
> Right, to be clear I'm saying that none of this is needed right now,
> i.e. I don't get why we'd want the scope-creep past the hunk I noted in
> https://lore.kernel.org/git/221128.868rjvmi3l.gmgdl@evledraar.gmail.com/
> for the --filter bug fix (plus the tests you're adding).
Well, you asked to squash the minimal fix into the laziness removal in
https://lore.kernel.org/git/221112.86bkpcmm6i.gmgdl@evledraar.gmail.com/
Reverting 5cb28270a1 (pack-objects: lazily set up "struct rev_info",
don't leak, 2022-03-28) wholesale is the simplest way to reach the goals
of regression fix, simplification and standard compliance. Except that
the leak check tests have come to depend on the leak being hidden in the
--filter corner. So going back to v1 sure seems attractive.
>
>>> I haven't dug into this one, but offhand I'm not confident in saying
>>> that this isn't exposing us to some aspect of that gnarlyness (maybe
>>> not, it's been a while since I looked).
>>
>> I saw it as the way towards a release_revisions() that calls diff_free()
>> itself: Add such calls to each of them, fix the "gnarlyness"
>> individually, finally move them all into release_revisions(). The only
>> problem is that there are 60+ callsites.
>
> I think this is a really bad approach in general.
>
> Yes, it may happen to work to free() some data from under an API, but
> it's just as likely that we'll miss that this one caller is screwing
> with its internal state, and e.g. when some new revision.c code is used
> it'll go boom.
>
> If we wanted to phase in such a free() of "foo" I think the right way
> would be to add some "revs.free_foo = 1" flag, giving the API a chance
> to treat that sanely, not to start poking at members of the struct, and
> assuming that its release() won't be free()-ing them.
And that's why you added no_free to struct diff_options. We could use
it here by setting it in repo_init_revisions() and unsetting in
cmd_pack_objects() and elsewhere, until it is set everywhere.
> But as noted above & in the linked I think we can defer all of that. The
> only reason we're discussing this is because you're changing the
> lazy-init to be not-lazy, and introducing new leaks as a result.>
> I've shown a couple of approaches in this thread of fixing the issue(s)
> at hand without introducing such leaks, so ...
As noted above: These leaks are not new, they are just moved into
test coverage.
René
next prev parent reply other threads:[~2022-11-28 15:56 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-12 10:42 [PATCH 0/3] pack-objects: fix and simplify --filter handling René Scharfe
2022-11-12 10:44 ` [PATCH 1/3] pack-objects: fix handling of multiple --filter options René Scharfe
2022-11-12 11:41 ` Ævar Arnfjörð Bjarmason
2022-11-13 17:31 ` René Scharfe
2022-11-12 16:58 ` Jeff King
2022-11-13 5:01 ` Taylor Blau
2022-11-13 16:44 ` Jeff King
2022-11-13 17:31 ` René Scharfe
2022-11-12 10:44 ` [PATCH 2/3] pack-object: simplify --filter handling René Scharfe
2022-11-12 11:45 ` Ævar Arnfjörð Bjarmason
2022-11-12 17:02 ` Jeff King
2022-11-13 16:49 ` Jeff King
2022-11-13 17:31 ` René Scharfe
2022-11-12 10:46 ` [PATCH 3/3] list-objects-filter: remove OPT_PARSE_LIST_OBJECTS_FILTER_INIT() René Scharfe
2022-11-20 10:03 ` [PATCH v2 0/3] pack-objects: fix and simplify --filter handling René Scharfe
2022-11-20 10:06 ` [PATCH v2 1/3] t5317: stop losing return codes of git ls-files René Scharfe
2022-11-20 10:07 ` [PATCH v2 2/3] t5317: demonstrate failure to handle multiple --filter options René Scharfe
2022-11-20 10:13 ` [PATCH v2 3/3] Revert "pack-objects: lazily set up "struct rev_info", don't leak" René Scharfe
2022-11-28 10:03 ` Junio C Hamano
2022-11-28 11:12 ` Ævar Arnfjörð Bjarmason
2022-11-28 12:00 ` [PATCH] t5314: check exit code of "rev-parse" Ævar Arnfjörð Bjarmason
2022-11-28 13:51 ` René Scharfe
2022-11-28 14:18 ` [PATCH v2] t5314: check exit code of "git" Ævar Arnfjörð Bjarmason
2022-11-28 11:26 ` [PATCH v2 3/3] Revert "pack-objects: lazily set up "struct rev_info", don't leak" René Scharfe
2022-11-28 11:31 ` Ævar Arnfjörð Bjarmason
2022-11-28 12:24 ` Ævar Arnfjörð Bjarmason
2022-11-28 15:16 ` René Scharfe
2022-11-28 15:27 ` Ævar Arnfjörð Bjarmason
2022-11-28 14:29 ` René Scharfe
2022-11-28 14:34 ` Ævar Arnfjörð Bjarmason
2022-11-28 15:56 ` René Scharfe [this message]
2022-11-28 17:57 ` René Scharfe
2022-11-28 18:32 ` Ævar Arnfjörð Bjarmason
2022-11-28 21:57 ` René Scharfe
2022-11-29 1:26 ` Jeff King
2022-11-29 1:46 ` Junio C Hamano
2022-11-29 10:25 ` Ævar Arnfjörð Bjarmason
2022-11-29 7:12 ` Ævar Arnfjörð Bjarmason
2022-11-29 19:18 ` René Scharfe
2022-11-28 17:57 ` Ævar Arnfjörð Bjarmason
2022-11-22 19:02 ` [PATCH v2 0/3] pack-objects: fix and simplify --filter handling Jeff King
2022-11-29 12:19 ` [PATCH v3 0/5] " René Scharfe
2022-11-29 12:21 ` [PATCH v3 1/5] t5317: stop losing return codes of git ls-files René Scharfe
2022-11-29 12:22 ` [PATCH v3 2/5] t5317: demonstrate failure to handle multiple --filter options René Scharfe
2022-11-29 12:23 ` [PATCH v3 3/5] pack-objects: fix handling of " René Scharfe
2022-11-30 1:09 ` Junio C Hamano
2022-11-30 7:11 ` René Scharfe
2022-11-29 12:25 ` [PATCH v3 4/5] pack-objects: simplify --filter handling René Scharfe
2022-11-29 13:27 ` Ævar Arnfjörð Bjarmason
2022-11-30 11:23 ` René Scharfe
2022-11-29 12:26 ` [PATCH v3 5/5] list-objects-filter: remove OPT_PARSE_LIST_OBJECTS_FILTER_INIT() René Scharfe
2022-11-30 1:20 ` 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
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=59431916-9f55-d0f4-da54-e7369803eb4c@web.de \
--to=l.s.r@web.de \
--cc=avarab@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.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.
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).