From: Julian Phillips Date: Fri, 13 Nov 2009 09:14:28 GMT Subject: Re: Git in next is broken Message-ID: In-Reply-To: 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]