Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 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
> >          at
> >          at
> >
> > ) at
> >
> > at
> > at
> > at org.eclipse.jgit.lib.ObjectStream$
> 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