Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Missing tree during self-tests on NonStop

> On March 2, 2015 11:51, I wrote:
> > -----Original Message-----
> > From: Shawn Pearce [mailto:spearce@xxxxxxxxxxx]
> > Sent: March 2, 2015 8:23 PM
> > To: Randall S. Becker
> > Cc: jgit-dev
> > Subject: Re: [jgit-dev] Missing tree during self-tests on NonStop
> >
> > On Wed, Feb 25, 2015 at 2:54 PM, Randall S. Becker
> > <rsbecker@xxxxxxxxxxxxx> wrote:
> > > I have a second issue that I am trying to resolve for our NonStop
> > > port. This
> > one is a failure in both GitConstructionTest and PushCommandTest. Both
> > have the virtually the same stack trace and look a little (maybe) like
> > bugs 445744 and 422988. Both tests point to the same missing tree id
> > (4b825dc6...). It seems like something in the FileObjectDatabase
> > hierarchy is not liking what the platform is doing with java.io.File,
> > but I am looking for a pointer to where to look next.
> > >
> > > testClose(org.eclipse.jgit.api.GitConstructionTest)  Time elapsed:
> > > 9.15 sec
> > <<< ERROR!
> > > org.eclipse.jgit.api.errors.JGitInternalException: Missing tree
> > > 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> >
> > My first check would be to look at the test repository on disk and see
> > if
> > $GIT_DIR/objects/4b/825dc642cb6eb9a060e54bf8d69288fbee4904 exists
> and
> > is a valid Git object. It seems there are some issues creating or
> > reading files through java.io due to Java doing "extra special logic"
> > on your platform. :(
> 
> I do know that the platform's JVM file create mode 755 instead of 644 by
> default, although I already changed FileUtils to explicitly remove execute
> access added by this platform's JVM. What I am suspecting, at this point, is that
> one or more of the following are creating commit misidentification problems
> for the tests, based on my previous findings on JDK 1.6 security assumptions by
> JGit invoking File.createNewFile() instead of FileUtils.createNewFile() below:
> 
> RebaseCommand.java:                  new File(rewrittenDir,
> commit.getName()).createNewFile();
> GC.java:           if (!tmpIdx.createNewFile())
> GC.java:           if (!tmpBitmapIdx.createNewFile())
> LockFile.java:     if (lck.createNewFile())
> InitCommandTest.java:           someFile.createNewFile();
> GcKeepFilesTest.java:          assertTrue(keepFile.createNewFile());
> RefDirectoryTest.java:         assertTrue(packedRefs.createNewFile());
> 
> If these are the issue, it is no trouble to change them but I think that using
> FileUtils might be more appropriate instead of java.io.File.

I am gradually making the changes to FileUtils, as appropriate, and incrementally testing. Things are improving but I had to modify JGitTestUtil .writeTrashFile, which is a bit pervasive - so this may not end well, but I will keep at it. More to come.

Cheers,
Randall
-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)
-- In real life, I talk too much.





Back to the top