From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 19:14:44 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5215D1065670 for ; Wed, 4 Jun 2008 19:14:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id EFF778FC12 for ; Wed, 4 Jun 2008 19:14:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=EsCsf81E53WSfPOV8X8sJUIg2QK0v9z9lPGGQn1qkrCgCIZQgq1i4wB3TvCFOdcSQ+yh9xNXbNuFrD1eAmNoaKXV6NRQfTmcFYtq4/PFzjiG7+KIXhVVVU1jMHvbmP6sq0JqypDsg8BJE7N3CfIcSuBIigtTLAkSyzMm3XmbkNM=; Received: from amnesiac.at.no.dns (ppp83-237-105-161.pppoe.mtu-net.ru [83.237.105.161]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1K3yRW-0001NB-M0; Wed, 04 Jun 2008 23:14:42 +0400 Date: Wed, 4 Jun 2008 23:14:41 +0400 From: Eygene Ryabinkin To: Chuck Robey Message-ID: References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> <4846B40A.4010309@telenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4846B40A.4010309@telenix.org> Sender: rea-fbsd@codelabs.ru Cc: FreeBSD-Hackers Subject: Re: git problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 19:14:44 -0000 Chuck, Wed, Jun 04, 2008 at 11:26:02AM -0400, Chuck Robey wrote: [...] > Looking at the top stack frame (main), that frame and the next are deeply > involved in inspecting argv 0 thru 2, and since it's full of garbage, that's > what breaks things. That's NOT malloc, that seems to be either a problem in > process creation or (I think more likely) a problem in the creation of a > process's environment, the crt0 stuff. I'm getting out of my depth, here. Sorry, I had thought about stack smashing, but it isn't it, so I somewhat guided people to the wrong way (if they were listening to me ;)) The real problem was the doubled call to the transport_unlock_pack() in the builtin-fetch.c. And the stack frame with __cxa_finalize was perfectly correct -- as I learned half an hour ago, it is the function that calls all handlers, registered with atexit(). So, the problem was the following: static function unlock_pack() in the builtin-fetch.c is the cleanup routine for the static variable 'transport'. And it calls transport_unlock_pack() if the 'transport' variable isn't NULL. But do_fetch() calls free(transport), so atexit's unlock_pack() tries to use already freed memory. The below patch works for me, although I should think about it once more to see if it handles all cases. Please, try the patch. --- builtin-fetch.c.orig 2008-06-04 22:49:05.000000000 +0400 +++ builtin-fetch.c 2008-06-04 23:07:51.000000000 +0400 @@ -598,7 +598,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) { struct remote *remote; - int i; + int i, retval; static const char **refs = NULL; int ref_nr = 0; @@ -654,6 +654,14 @@ signal(SIGINT, unlock_pack_on_signal); atexit(unlock_pack); - return do_fetch(transport, + retval = do_fetch(transport, parse_fetch_refspec(ref_nr, refs), ref_nr); + /* + * Set transport to NULL, because its contents are already + * freed in do_fetch(), so we mustn't deinitialize it in + * unlock_pack(). + */ + transport = NULL; + + return retval; } -- Eygene