[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] JGit corrupts blobs or hangs forever
|
On Thu, Nov 24, 2011 at 14:20, Dmitry Pavlenko <dmit10@xxxxxxxxx> wrote:
> I've encountered into the problem when using JGit. It happens if
> * the blob is packed
> * the blob is kept as delta within the pack
> * there's no corresponding loose object for the blob (so JGit is forced to read the pack file)
>
> With some older JGit version the test fails on comparison of expected and actual values at i=8192.
> With the latest JGit master the test below hangs forever with the stack:
What latest JGit master commit did you use? As of
b4495d1005e6e03e921ed116614ec45499f1923d (master as I write this) I am
unable to reproduce the hang. I tried both streamFileThreshold = 50M
(default) and 10M (below the ~40M blob size).
This was tested with Mac OS X JRE 1.6.0_26-b03-383-11A511, the pack
was created using Git 1.7.7.3. I looked at the pack after it was
built, it is a delta:
75dee3868ecd555ddbfb328de3ebb6366afb9ddf blob 40000000 155477 12
c0dc671128cb9ea59a0c5033521a81d0cab48c91 blob 2199 1091 155489 1
75dee3868ecd555ddbfb328de3ebb6366afb9ddf
blob1Id = 75dee3868ecd555ddbfb328de3ebb6366afb9ddf
blob2Id = c0dc671128cb9ea59a0c5033521a81d0cab48c91
So this is the case you were testing, the 2nd blob is a delta on the
1st. I checked that before the open(blob2Id) call is made, there are
no loose objects, and after the c0dc object is loose again, which
means JGit saw it as a large delta and unpacked it loose in the loose
object directory.
> at java.util.zip.Deflater.deflateBytes(Deflater.java:-1)
> at java.util.zip.Deflater.deflate(Deflater.java:306)
> at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:159)
> at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
> at org.eclipse.jgit.util.io.TeeInputStream.read(TeeInputStream.java:113)
> at org.eclipse.jgit.util.io.TeeInputStream.read(TeeInputStream.java:87)
> at org.eclipse.jgit.lib.ObjectStream$Filter.read(ObjectStream.java:204)
Are you sure its stuck and not just taking a long time to execute? We
are inflating and then immediately deflating 40M worth of data in this
test, and writing that deflated data back out as a loose object. The
deflation is handled by the platform's DeflaterOutputStream, so we
shouldn't be subject to any corner case bugs in JGit here, we are just
passing off the inflated chunks to the platform's DeflaterOutputStream
and letting that deflate and write those deflated chunks to the
underlying FileOutputStream.
