Re: Debugging corrupt object generation

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Nov 2, 2007, 00:26 UTC
Message-ID: <Pine.LNX.4.64.0711020018400.18429@beast.quantumfyre.co.uk>
In-Reply-To: <alpine.LFD.0.9999.0711011947220.21255@xanadu.home>

On Thu, 1 Nov 2007, Nicolas Pitre wrote:

Show 8 quoted lines

> On Thu, 1 Nov 2007, Julian Phillips wrote:
>
>> After a certain commit, and attempt to use that commit generates a "fatal:
>> unable to apply delta".  This appears to be coming from unpack_delta_entry
>> in sha1_file.c.
>
> I suppose you mean "fatal: failed to apply delta", because "unable to
> apply delta" doesn't appear anywhere in the current source tree.

I did indeed. Read 'n' type never seems to be as reliable as copy 'n' paste ...

Show 7 quoted lines

>> Can anyone give me any hints as to how I find out what is causing the
>> problem?  I'm not even sure what it is that isn't working ... and all
>> attempts to replicate the problem with my test repository have failed.
>
> Well, something is screwed for sure.  Some object you're requesting is
> made of a delta, and that delta is bad, therefore patch_delta() returns
> NULL (you could instrument it to determine exactly why).

Ah, ok - that sounds like it might be useful. I guess that looking at the opposite side where fast-import is creating the data might also prove fruitful.

> Maybe fast-import hasn't flushed the needed data to the pack yet?

Well, fast-import completes quite happily and outputs the normal summary status. I can look at logs and trees etc provided that I don't try and look at one particular part of the tree on one particular commit. I think the problem is that I've managed to do something inside fast-import that corrupts one particular tree object (though I've no idea what that might be).

I shall have to start instrumenting and try again.

Thanks.

-- 
Julian

  ---
Many changes of mind and mood; do not hesitate too long.