git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH 1/1] remote-curl: unbreak http.extraHeader with custom allocators
Date: Wed, 6 Nov 2019 10:14:37 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1911061009230.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20191106041644.GE4307@sigill.intra.peff.net>

Hi Peff,

On Tue, 5 Nov 2019, Jeff King wrote:

> On Tue, Nov 05, 2019 at 09:59:18PM +0000, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > In 93b980e58f5 (http: use xmalloc with cURL, 2019-08-15), we started to
> > ask cURL to use `xmalloc()`, and if compiled with nedmalloc, that means
> > implicitly a different allocator than the system one.
> >
> > Which means that all of cURL's allocations and releases now _need_ to
> > use that allocator.
> >
> > However, the `http_options()` function used `slist_append()` to add any
> > configured extra HTTP header(s) _before_ asking cURL to use `xmalloc()`,
> > and `http_cleanup()` would release them _afterwards_, i.e. in the
> > presence of custom allocators, cURL would attempt to use the wrong
> > allocator to release the memory.
> >
> > Let's fix this by moving the initialization _before_ the
> > `http_options()` function is called.
>
> Nicely explained.
>
> Another option would be to separate our config mechanism from curl
> entirely by putting the list of headers into a string_list, and then
> transforming it later into a curl_slist. I don't think that really buys
> us much, though.

Alas, it _does_ buy us a lot, as I *just* found out (can you imagine how
glad I am not to have rushed out another Git for Windows release?). It
buys us one less bug: my patch introduces the bug where
`http.sslbackend` can no longer be used, because `curl_global_sslset()`
needs to be called _before_ `curl_global_init()`, but my patch breaks
that because we _need_ to parse the config before we can ask cURL for a
specific backend.

> This is all inside http.c, so it's fairly contained.  It's not like
> other random parts of Git are using curl's slist before calling
> http_init().

Indeed. We cannot use cURL's slist anywhere outside of the
cURL-dependent code because we want to keep `NO_CURL=Yep` working.

> I did briefly grep around for other slist users, but they're all what
> you'd expect: code in http-push.c and remote-curl.c creating header
> lists while working with an active http request (so well after
> http_init() has been called).

Indeed, I came to the same conclusion that Carlo's patch only broke
support for `http.extraheaders` (and only with custom allocators),
nothing else.

I will change the patch to avoid using `slist` early and send another
iteration.

Thanks,
Dscho

> > ---
> >  http.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
>
> The patch itself looks good.
>
> -Peff
>

  reply	other threads:[~2019-11-06  9:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 21:59 [PATCH 0/1] remote-curl: unbreak http.extraHeader with custom allocators Johannes Schindelin via GitGitGadget
2019-11-05 21:59 ` [PATCH 1/1] " Johannes Schindelin via GitGitGadget
2019-11-06  4:16   ` Jeff King
2019-11-06  9:14     ` Johannes Schindelin [this message]
2019-11-06  9:49       ` Junio C Hamano
2019-11-06 19:38         ` Johannes Schindelin
2019-11-08  8:34           ` Junio C Hamano
2019-11-08 13:44             ` Johannes Schindelin
2019-11-06 10:04 ` [PATCH v2 0/1] " Johannes Schindelin via GitGitGadget
2019-11-06 10:04   ` [PATCH v2 1/1] " Johannes Schindelin via GitGitGadget
2019-11-06 11:29     ` Jeff King
2019-11-06 12:12     ` Junio C Hamano
2019-11-06 19:34       ` Johannes Schindelin
2019-11-07  5:39         ` Junio C Hamano
2019-11-07 12:40           ` Johannes Schindelin
2019-11-08  3:03             ` Junio C Hamano
2019-11-06 12:15   ` [PATCH v2 0/1] " 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=nycvar.QRO.7.76.6.1911061009230.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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).