On Mon, Sep 27, 2010 at 04:19, Fredrik Luthander
<
fredrik....@sonyericsson.com> wrote:
> Yesterday, my team at $DAYJOB tried to upgrade Gerrit from version
> 2.1.3-rc2 to 2.1.5-85-ge5669ac (mostly to have the missing blob fix
> specifically submitted for us). This upgrade however, was not
> successful, and in the end we had to back down to the 2.1.3 version
> again.
>
> The upgrade itself was fine, however the following tests were not
> successful. A specific git yields error when trying to replicate it.
>
> The symptom is as follows:
>
> The upgraded gerrit service is started.
> First person to sync/fetch from the server can successfully get the
> git together with other gits.
> All following attempts to sync the git yields the following error:
...
> [2010-09-27 02:06:47,311] ERROR com.google.gerrit.sshd.BaseCommand :
> Internal server error (user cecilia.svensson account 1000032) during
> git-upload-pack '/path/icu4c.git'
> org.eclipse.jgit.errors.CorruptObjectException: Object
> 86be6cbcd3527245d5cd9961dbdede05d2877268 is corrupt: incorrect length
> at
> org.eclipse.jgit.storage.file.UnpackedObject.checkValidEndOfStream(UnpackedObject.java:
> 250)
Someone just reported a similar issue on the jgit-dev mailing list.
What is occurring is this:
During the first fetch/clone an object bigger than the
core.streamFileThreshold is encountered. The object is inflated and a
copy is stored as a loose object in $GIT_DIR/objects. This is because
the inflation cost of a delta bigger than the threshold is very high,
so we cache the object so that later accesses of the same thing are
cheaper.
On the second access the loose object is used instead, but its
consistency check on the end of the stream fails. This is the bug
that just got reported on the jgit-dev list earlier this morning.
If you set core.streamFileThreshold very big (e.g. 2047m) in
gerrit.config you can bypass all of this logic and avoid the bug.
This is what "my" servers are using right now.