git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Matthias Aßhauer" <mha1993@live.de>,
	git@vger.kernel.org, "Elijah Newren" <newren@gmail.com>,
	"Johannes Schindelin" <johannes.schindelin@gmx.de>
Subject: Re: gitk regression in version 2.36.0
Date: Sat, 23 Apr 2022 09:00:24 -0700	[thread overview]
Message-ID: <xmqqh76j3i3r.fsf@gitster.g> (raw)
In-Reply-To: <737bd2f8-dfd7-6a51-b7f5-33eefa33e975@web.de> ("René Scharfe"'s message of "Sat, 23 Apr 2022 12:13:11 +0200")

René Scharfe <l.s.r@web.de> writes:

>> I am reasonably sure that reverting that commit will be the right
>> thing to do.  It is somewhat unfortunate that it would reintroduce
>> resource leaks that having clear_pathspec() in a wrong place (i.e.
>> diff_free()) was covering up.  We should instead need to find the
>> place where a diff_opt struct goes out of scope (after being used
>> for zero or more times, calling diff_free() after each iteration to
>> release resources consumed per-iteration) and call clear_pathspec().
>
> Right; a small memory leak is better than wrong output.

Yeah, it is an absolute requirement to avoid producing wrong output,
and when producing output for 100 or 1000 commits, we should not
leak resources in proportion to the number of these commits
processed, so forgetting to call diff_free() that releases resources
that are required per diff-invocation is also a must.  Compared to
that, cleaning up the resource allocated just once and repeatedly
used while we handle these 100 or 1000 commits, while it is nice to
do so, is of much lower priority, certainly much lower than computing
the right result.

> Finding those places is a bit complicated by diff_options often being
> embedded in struct rev_info, though.

Perhaps, but we should have a resource-releasing helper for rev_info,
so that may be a good place to do so, hopefully.

Thanks

> PS: And I need to learn to download new posts before hitting Send
> (or become faster); sorry for my near-duplicate reply.

Actually this time I very much appreciated an independent validation
of my findings ;-)  Thanks.

  reply	other threads:[~2022-04-23 16:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-23  5:25 gitk regression in version 2.36.0 Matthias Aßhauer
2022-04-23  5:54 ` Junio C Hamano
2022-04-23  6:05   ` Junio C Hamano
2022-04-23 10:13   ` René Scharfe
2022-04-23 16:00     ` Junio C Hamano [this message]
2022-04-25 17:45       ` [PATCH] 2.36 gitk/diff-tree --stdin regression fix Junio C Hamano
2022-04-25 22:37         ` [PATCH] t4013: diff-tree --stdin with pathspec Junio C Hamano
2022-04-26 10:09         ` [PATCH] 2.36 gitk/diff-tree --stdin regression fix Phillip Wood
2022-04-26 13:45           ` Phillip Wood
2022-04-26 15:16             ` Junio C Hamano
2022-04-26 15:26             ` Junio C Hamano
2022-04-26 16:11               ` Junio C Hamano
2022-04-27 16:42                 ` René Scharfe
2022-04-27 18:06                   ` René Scharfe
2022-04-27 20:03                     ` Junio C Hamano
2022-04-23  9:27 ` gitk regression in version 2.36.0 René Scharfe

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=xmqqh76j3i3r.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=l.s.r@web.de \
    --cc=mha1993@live.de \
    --cc=newren@gmail.com \
    /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).