On Thu, 12 Nov 2009, Nicolas Pitre wrote:
On Thu, 12 Nov 2009, Julian Phillips wrote:
On Thu, 12 Nov 2009, Ren? Scharfe wrote:
Nicolas Pitre schrieb:
Simply issuing a "git fetch" in my copy of git.git makes glibc complain
with this:
*** glibc detected *** git: corrupted double-linked list:
0x0000000000974180 ***
Can't reproduce because I don't know how to create duplicate refs, but does
the following help?
Nope.
remote.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index 4f9f0cc..10cc985 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = next;
You don't need this line (this is taken care of in the for(...)).
+ continue;
Ack. This one however, you do need. Good catch.
Without the "ref_map = next" there is no change: glibc still complains
about corruption and abort the execution. With the "ref_map = next"
then git simply segfaults.
I simply have zero time to investigate the issue myself now
unfortunately.
I was half right about "ref_map = next", I had forgotten about setting
prev in the for(...). For me, the following fixes it on MacOS (I don't
have time to test on Linux right now):
diff --git a/remote.c b/remote.c
index 4f9f0cc..6195a58 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = prev; // Keep the same prev.
+ continue;
}
item = string_list_insert(ref_map->peer_ref->name, &refs);
--
Julian
---
C'est magnifique, mais ce n'est pas l'Informatique.
-- Bosquet [on seeing the IBM 4341]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html