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 *** > > > > > > The gdb backtrace is: > > > > > > (gdb) bt > > > #0 0x0000003c76632f05 in raise () from /lib64/libc.so.6 > > > #1 0x0000003c76634a73 in abort () from /lib64/libc.so.6 > > > #2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6 > > > #3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6 > > > #4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6 > > > #5 0x0000003c7667a486 in free () from /lib64/libc.so.6 > > > #6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0) > > > at remote.c:756 > > > #7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165 > > > #8 do_fetch () at builtin-fetch.c:644 > > > #9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0, > > > prefix=<value optimized out>) at builtin-fetch.c:754 > > > #10 0x0000000000403d83 in run_builtin () at git.c:251 > > > #11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396 > > > #12 0x0000000000403f2d in run_argv () at git.c:438 > > > #13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509 > > > > > > Bisection reveals the following culprit: > > > > > > commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776 > > > Author: Julian Phillips <julian@xxxxxxxxxxxxxxxxx> > > > Date: Sun Oct 25 21:28:11 2009 +0000 > > > > > > remote: Make ref_remove_duplicates faster for large numbers of refs > > > > 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. Nicolas -- 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