Re: Git crashes on pull

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2009, 22:54 UTC
Message-ID: <7vzl8v4y5g.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LSU.2.01.0909160022430.24554@bianca.dialin.t-online.de>

Guido Ostkamp <git@ostkamp.fastmail.fm> writes:

Show 15 quoted lines

> On Tue, 15 Sep 2009, Junio C Hamano wrote:
>
>> Please try this patch, which I have been preparing for later pushout.
>>
>> From: Junio C Hamano <gitster@pobox.com>
>> Date: Mon, 14 Sep 2009 14:48:15 -0700
>> Subject: [PATCH] http.c: avoid freeing an uninitialized pointer
>>
>> An earlier 59b8d38 (http.c: remove verification of remote packs) left
>> the variable "url" uninitialized; "goto cleanup" codepath can free it
>> which is not very nice.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Appears to be working ok now, thanks.

Thanks.

The sad part of the story was that this regression was introduced by a change to work around recent breakage observed when fetching from the http server github runs, and it was the primary purpose of pushing 1.6.4.3 out.

Now we need to cut a 1.6.4.4 with this fix-on-fix soon, like tomorrow.

Show 6 quoted lines

> BTW: Is there any way to easily invoke GDB in case of such a problem
> to get a real symbolic stack backtrace?
>
> I tried it on the 'git' binary, but of course this didn't work because
> it invokes a git-pull script which again runs another git-remote-curl
> binary.

Not very easily. The best you can do is to run with GIT_TRACE to see what command actually dies and run that binary directly. gdb can choose to follow either parent or child across forks, but I do not know how to tell it to follow across execs into a different binary.