[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC PATCH v3 00/17] Return of smart HTTP
From:       "Shawn O. Pearce" <spearce () spearce ! org>
Date:       2009-10-15 15:41:42
Message-ID: 20091015154142.GL10505 () spearce ! org
[Download RAW message or body]

Johan Herland <johan@herland.net> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]