All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, "Justin Tobler" <jltobler@gmail.com>,
	"Mitja Bezenšek" <mitja.bezensek@login5.org>,
	gitster@pobox.com
Subject: Re: [PATCH v5 1/3] transport: add `transport_options_release()`
Date: Thu, 29 Oct 2026 09:07:11 +0100	[thread overview]
Message-ID: <auL-r__SD8m3it5h@pks.im> (raw)
In-Reply-To: <CAOLa=ZTCwvUJNj6c1G8dU778ejwO5WvVL9F5C-Db=P4Au5=mQA@mail.gmail.com>

On Wed, Oct 28, 2026 at 04:18:11PM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Wed, Oct 28, 2026 at 10:47:59AM +0100, Karthik Nayak wrote:
> >> The `git_transport_options` structure is used both in 'transport.c' and
> >> 'transport-helper.c'. But while the former specifically clears any
> >> associated data in the structure during the cleanup of the transport,
> >> the latter misses this.
> >>
> >> This means when using remote-helpers, data allocated for the structure
> >> leaks. Introduce a new `transport_options_release()`, which acts as a
> >
> > Nit: "a new transport_options_release" reads a bit weird. I'd either add
> > "function", or drop "a new".
> >
> 
> Fair enough, I'll drop the 'a new'.
> 
> >> common path to release memory allocated with the structure and use it in
> >> both files.
> >
> > Why didn't our CI detect this leak? Don't we have tests exercising this?
> >
> > The patch itself looks obviously good to me, thanks.
> >
> > Patrick
> 
> We don't have any tests which exercise this it seems. The tests in the
> next patch do, which is why it hit the bug!

That would have been great to point out in the commit message :) Thanks
for clarifying!

Patrick

  reply	other threads:[~2026-10-29  8:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 22:10 [PATCH] fetch: commit references fetched before backfilling tags Karthik Nayak
2026-10-09 11:26 ` Patrick Steinhardt
2026-10-09 16:51   ` Justin Tobler
2026-10-09 22:16     ` Karthik Nayak
2026-10-09 22:31   ` Karthik Nayak
2026-10-12 15:29 ` [PATCH v2] " Karthik Nayak
2026-10-12 19:55   ` Junio C Hamano
2026-10-15 10:31     ` Karthik Nayak
2026-10-15 21:24 ` [PATCH v3] " Karthik Nayak
2026-10-20 23:05   ` Justin Tobler
2026-10-21  6:39     ` Patrick Steinhardt
2026-10-21 10:01       ` Karthik Nayak
2026-10-21 13:59         ` Justin Tobler
2026-10-22  9:13           ` Karthik Nayak
2026-10-21 10:05     ` Karthik Nayak
2026-10-22 21:00 ` [PATCH v4] fetch: advertise fetched refs when " Karthik Nayak
2026-10-23  6:40   ` Patrick Steinhardt
2026-10-23 10:58     ` Karthik Nayak
2026-10-23 12:00       ` Patrick Steinhardt
2026-10-23 22:01         ` Karthik Nayak
2026-10-23 22:12           ` Karthik Nayak
2026-10-28  9:47 ` [PATCH v5 0/3] " Karthik Nayak
2026-10-28  9:47   ` [PATCH v5 1/3] transport: add `transport_options_release()` Karthik Nayak
2026-10-28 11:42     ` Patrick Steinhardt
2026-10-28 20:18       ` Karthik Nayak
2026-10-29  8:07         ` Patrick Steinhardt [this message]
2026-10-29 10:02           ` Karthik Nayak
2026-10-28  9:48   ` [PATCH v5 2/3] fetch: advertise fetched refs when backfilling tags Karthik Nayak
2026-10-28  9:48   ` [PATCH v5 3/3] t5510: cover upstream info update on fetch failure Karthik Nayak
2026-10-28 11:42     ` Patrick Steinhardt
2026-10-28 20:19       ` Karthik Nayak
2026-10-29 12:45 ` [PATCH v6 0/3] fetch: advertise fetched refs when backfilling tags Karthik Nayak
2026-10-29 12:45   ` [PATCH v6 1/3] t5510: cover upstream info update on fetch failure Karthik Nayak
2026-10-29 12:45   ` [PATCH v6 2/3] transport: add `transport_options_release()` Karthik Nayak
2026-10-29 12:45   ` [PATCH v6 3/3] fetch: advertise fetched refs when backfilling tags Karthik Nayak
2026-10-29 14:00   ` [PATCH v6 0/3] " Patrick Steinhardt

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=auL-r__SD8m3it5h@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jltobler@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=mitja.bezensek@login5.org \
    /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.