|Re: [jgit-dev] JGit corrupts blobs or hangs forever|
I used master b4495d1005e6e03e921ed116614ec45499f1923d. Yes, it just takes rather long time to execute, but not forever, you're right. My JVM is java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) > 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 188.8.131.52. 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.
Back to the top