Johan Herland <johan@xxxxxxxxxxx> wrote: > Don't have time to look into this at the moment, but a cursory gdb > shows that the "git fetch" in test #4 in t9801 segfaults with the > following stacktrace: > > #0 0x00007f8dd67e8a47 in fclose () from /lib/libc.so.6 > #1 0x00000000004a05b5 in disconnect_helper (transport=<value optimized out>) at transport-helper.c:81 > #2 0x000000000049de1e in transport_disconnect (transport=0x1955490) at transport.c:952 > #3 0x0000000000423477 in cmd_fetch (argc=26566704, argv=0x0, prefix=<value optimized out>) at builtin-fetch.c:748 > #4 0x0000000000404233 in handle_internal_command (argc=2, argv=0x7fffdf293d20) at git.c:251 > #5 0x0000000000404426 in main (argc=2, argv=0x7fffdf293d20) at git.c:438 It does. It is caused by the disconnect_helper call inside of fetch_with_import. You can't disconnect inside of the fetch method of a transport, the caller is going to disconnect you a second time. During that second disconnect the transport->data field is now pointing at a garbage area of memory. We're passing a garbage pointer from data->out to fclose, and fclose is rightly upset. This bug isn't due to the merge, its a bug in Johan's series that needs to be fixed before it could merge down to next/master. -- Shawn. -- 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