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.
next prev parent 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.