Re: Debugging corrupt object generation

On Thu, 1 Nov 2007, Nicolas Pitre wrote:

On Thu, 1 Nov 2007, Julian Phillips wrote:

quoted

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 ...

quoted

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.