All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Ing. Martin Prantl Ph.D." <perry@ntis.zcu.cz>
Cc: Glen Choo <chooglen@google.com>, git@vger.kernel.org
Subject: Re: Bug - remote.c:236: hashmap_put overwrote entry after hashmap_get returned NULL
Date: Thu, 19 May 2022 02:58:34 -0400	[thread overview]
Message-ID: <YoXqmrOTxD5MiDU1@coredump.intra.peff.net> (raw)
In-Reply-To: <24f547-6285e280-59-40303580@48243747>

On Thu, May 19, 2022 at 08:23:25AM +0200, Ing. Martin Prantl Ph.D. wrote:

> file:.git/config    branch..remote=origin
> file:.git/config    branch..merge=refs/heads/
> [...]
> 
> git ls-remote
> BUG: remote.c:236: hashmap_put overwrote entry after hashmap_get returned NULL

Those branch entries with an empty subsection are the culprit. I'm not
sure how they got there, but they should be safe to remove, which will
make your immediate problem go away.

It looks like handling of such bogus keys regressed in 4a2dcb1a08
(remote: die if branch is not found in repository, 2021-11-17). In
make_branch(), the call to find_branch() gets confused by the 0-length
"len" parameter, and instead uses strlen() on the partial string
containing the rest of the config key. So it tries to look up branch
".remote" for the first key, and ".merge" for the second. Since neither
exist, in both cases it then tries to add a new entry, but this time
correctly using the 0-length string. Which will confusingly already be
present when handling the second key.

Either find_branch() needs to become more careful about distinguishing
the two cases, or perhaps 0-length names should be rejected earlier (I
don't think they could ever be useful).

Perhaps something like this, though I'll leave it to the original author
(cc'd) to decide what's best.

diff --git a/remote.c b/remote.c
index 42a4e7106e..2f000a6416 100644
--- a/remote.c
+++ b/remote.c
@@ -354,7 +354,7 @@ static int handle_config(const char *key, const char *value, void *cb)
 	struct remote_state *remote_state = cb;
 
 	if (parse_config_key(key, "branch", &name, &namelen, &subkey) >= 0) {
-		if (!name)
+		if (!name || !namelen)
 			return 0;
 		branch = make_branch(remote_state, name, namelen);
 		if (!strcmp(subkey, "remote")) {

-Peff

  reply	other threads:[~2022-05-19  7:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19  6:23 Bug - remote.c:236: hashmap_put overwrote entry after hashmap_get returned NULL Ing. Martin Prantl Ph.D.
2022-05-19  6:58 ` Jeff King [this message]
2022-05-28  0:12   ` Glen Choo
2022-05-28  0:13   ` Glen Choo

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=YoXqmrOTxD5MiDU1@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=chooglen@google.com \
    --cc=git@vger.kernel.org \
    --cc=perry@ntis.zcu.cz \
    /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.