Re: [jgit-dev] UnpackedObject and CorruptObjectException

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Mon, Oct 4, 2010 at 9:19 AM, Marc Strapetz <marc.strapetz@xxxxxxxxxxx> wrote:
> I'm receiving following Exception when invoking RenameDetector. I have
> no problems when performing "git diff" for the same commit. How should I
> proceed with debugging?
>
> Caused by: org.eclipse.jgit.errors.CorruptObjectException: Object
> 41ab2dcc9c58bebb80672f39220e74baead07e1f is corrupt: incorrect length
>        at
> org.eclipse.jgit.storage.file.UnpackedObject.checkValidEndOfStream(UnpackedObject.java:250)

Check that the remaining field on line 287 of UnpackedObject.java is
initialized with the same size that `git cat-file -s` says for that
object.  It should be, because that is the size of the object from the
object header.

Check that the SimilarityIndex actually read that many bytes, and thus
during close() that remaining == 0.

If the above is all true, we shouldn't be getting extra data from
inflate on UnpackedObject.java line 244... but we are.  Which
indicates something is wrong.  No clue what.  C Git should also be
doing this check so I'm surprised its not failing.

Hmm, something else to look at.  Line 287 overrides the JRE's
InflaterInputStream.  But only overrides the read(byte[], int, int)
method.  It doesn't override the other methods, which means we might
not be updating remaining correctly for every case.  But I was pretty
sure this was OK because we wrap it into a BufferedInputStream and we
almost always use the read(byte[], int, int) format within JGit.


Sorry, that's all I've got for now.  The baby is starting to make
noise that I might need to go pay more attention to...

-- 
Shawn.