|Re: [jgit-dev] DirCacheTree: ArrayIndexOutOfBoundsExceptio|
On Mon, Dec 13, 2010 at 12:47 AM, Marc Strapetz <marc.strapetz@xxxxxxxxxxx> wrote: > One of our users has reported following problem with jgit, commit > d29b5db695225ed9629b028f99070bd182320b0f: > > java.lang.ArrayIndexOutOfBoundsException: 29 > at org.eclipse.jgit.dircache.DirCacheTree.getChild(DirCacheTree.java:249) > at > org.eclipse.jgit.dircache.DirCacheIterator.parseEntry(DirCacheIterator.java:217) > at > org.eclipse.jgit.dircache.DirCacheIterator.next(DirCacheIterator.java:196) > at org.eclipse.jgit.treewalk.TreeWalk.popEntriesEqual(TreeWalk.java:931) > at org.eclipse.jgit.treewalk.TreeWalk.next(TreeWalk.java:544) > > According to his bug report, he had to re-clone the repository to get > rid of the problem. Shall I ask user for anything else which may be > helpful to track down the cause? Was the TreeWalk an instance of TreeWalk, or NameConflictTreeWalk? You said the user got rid of the problem by re-cloning the repository. That seems to suggest that the user just needed to throw away his current $GIT_DIR/index file and start from scratch, which meant the DirCacheIterator above is an iterator over the current $GIT_DIR/index file. Somehow the trees within that file confused the iterator state. Do you know if he ever used C Git against that repository? I think the problem here is DirCacheIterator's nextSubtreePos got out of sync with ptr, resulting in it asking some subtree for an element that didn't exist in the subtree. Right now the only way I can think of that occurring is if NameConflictTreeWalk is being used and DirCacheIterator's back(int) method is broken. -- Shawn.
Back to the top