All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, man dog <dogman888888@gmail.com>
Subject: Re: [PATCH 3/3] diff.c: use diff_free_queue()
Date: Mon, 7 Nov 2022 17:13:11 +0100	[thread overview]
Message-ID: <20221107161311.GC1951@szeder.dev> (raw)
In-Reply-To: <Y2MKKTz4nK0L8uW5@nand.local>

On Wed, Nov 02, 2022 at 08:24:09PM -0400, Taylor Blau wrote:
> On Wed, Nov 02, 2022 at 11:01:42PM +0100, SZEDER Gábor wrote:
> >  int diff_flush_patch_id(struct diff_options *options, struct object_id *oid, int diff_header_only)
> >  {
> >  	struct diff_queue_struct *q = &diff_queued_diff;
> > -	int i;
> >  	int result = diff_get_patch_id(options, oid, diff_header_only);
> >
> > -	for (i = 0; i < q->nr; i++)
> > -		diff_free_filepair(q->queue[i]);
> > -
> > -	free(q->queue);
> > +	diff_free_queue(q);
> >  	DIFF_QUEUE_CLEAR(q);
> 
> So, this all looks fine to me. But I did a quick grep around for
> DIFF_QUEUE_CLEAR(), and this macro is used in quite a few places.
> Mostly, as far as I can tell, to "empty" out the diff-queue by setting
> its 'queue' pointer to NULL, and its 'nr' back to 0.
> 
> Should we be freeing the memory held by the queue there more
> aggressively? I.e., should we make sure that there is a
> diff_free_queue() call above each expansion of the DIFF_QUEUE_CLEAR()
> macro?

Definitely not.  DIFF_QUEUE_CLEAR is often used to initialize a just
created 'struct diff_queue_struct' instance; by adding a
diff_free_queue() above those it would operate on uninitialized
memory.


  reply	other threads:[~2022-11-07 16:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-29 16:59 Bug report: git -L requires excessive memory man dog
2022-10-31 21:45 ` SZEDER Gábor
2022-10-31 21:56   ` Taylor Blau
2022-11-02 22:01     ` [PATCH 0/3] line-log: plug some memory leaks SZEDER Gábor
2022-11-02 22:01       ` [PATCH 1/3] line-log: free diff queue when processing non-merge commits SZEDER Gábor
2022-11-03  0:20         ` Taylor Blau
2022-11-07 15:11           ` SZEDER Gábor
2022-11-07 15:29             ` Ævar Arnfjörð Bjarmason
2022-11-07 15:57               ` SZEDER Gábor
2022-11-08  2:14                 ` Taylor Blau
2022-11-02 22:01       ` [PATCH 2/3] line-log: free the diff queues' arrays when processing merge commits SZEDER Gábor
2022-11-03  0:21         ` Taylor Blau
2022-11-02 22:01       ` [PATCH 3/3] diff.c: use diff_free_queue() SZEDER Gábor
2022-11-03  0:24         ` Taylor Blau
2022-11-07 16:13           ` SZEDER Gábor [this message]
2022-11-08  2:14             ` Taylor Blau
2022-11-03  9:05       ` [PATCH 0/3] line-log: plug some memory leaks Ævar Arnfjörð Bjarmason

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=20221107161311.GC1951@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=dogman888888@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.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.
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.