Re: Segmentation fault with latest git (070c57df)

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2013, 16:46 UTC
Message-ID: <7vboc03u3e.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130204093821.GA32095@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 21 quoted lines

> On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:
>
>> I think this really boils down to where we draw the "this is good
>> enough" line.  I am not sure if losing the file as in $gmane/215211
>> is common enough to be special cased to buy us much, while leaving
>> other ".depend/foo.o.d was updated to contain a wrong info" cases
>> still broken.
>
> Hmm. Yeah, I was thinking it might be more common than ordinary munging
> due to something like an interrupted "git clean -x". But given that:
>
>   1. As far as I can tell, it is not a situation that can happen through
>      regular use of checkout/make/etc, and...
>
>   2. We have zero reports of it happening in practice (I only discovered
>      it while explicitly trying to break the Makefile), and...
>
>   3. It is just one of many possible breakages, all of which can be
>      fixed by "git clean -dx" if you suspect issues...
>
> let's just leave it. Thanks for a sanity check.

The only case that worries me is when make or cc gets interrupted. As long as make removes the ultimate target *.o in such a case, it is fine to leave a half-written .depend/foo.o.d (or getting it removed) behind.

How expensive to generate the dependency for a single foo.c file into a temporary without compiling it into foo.o, and comparing the resulting dependency with existing .depend/foo.o.d? If it is very cheap, it might be worth doing it before linking the final build product and error the build out when we see discrepancies. I dunno.