[
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.