Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348834

Summary:	History page loops
Product:	[Technology] JGit	Reporter:	Robin Rosenberg <robin.rosenberg>
Component:	JGit	Assignee:	Project Inbox <jgit.core-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	P3
Version:	1.0
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Robin Rosenberg

2011-06-09 03:02:21 EDT

Eclipse EGit    1.0.0.201106081625-r    org.eclipse.egit.feature.group
  Eclipse JGit    1.0.0.201106081625-r    org.eclipse.jgit.feature.group

Eclipse 3.6.2

When requesting history for patch 4 in http://egit.eclipse.org/r/#change,3645,patchset=4 the history page loops.

HEAD is 9b953b4fc900011c9266120170a905e98d3c262d  and the resource that I dragged to the history page is org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewRepoHandlingTest.java

The job seems unstoppable, but it is possible to quit Eclipse normally.

Worker-11" prio=5 tid=1144ba800 nid=0x125d01000 runnable [125d00000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jgit.storage.file.PackFile.idx(PackFile.java:154)
        - locked <7d66442f0> (a org.eclipse.jgit.storage.file.PackFile)
        at org.eclipse.jgit.storage.file.PackFile.get(PackFile.java:226)
        at org.eclipse.jgit.storage.file.ObjectDirectory.openObject1(ObjectDirectory.java:439)
        at org.eclipse.jgit.storage.file.FileObjectDatabase.openObjectImpl1(FileObjectDatabase.java:172)
        at org.eclipse.jgit.storage.file.FileObjectDatabase.openObject(FileObjectDatabase.java:157)
        at org.eclipse.jgit.storage.file.WindowCursor.open(WindowCursor.java:122)
        at org.eclipse.jgit.treewalk.CanonicalTreeParser.reset(CanonicalTreeParser.java:193)
        at org.eclipse.jgit.treewalk.TreeWalk.reset(TreeWalk.java:428)
        at org.eclipse.jgit.revwalk.RewriteTreeFilter.include(RewriteTreeFilter.java:116)
        at org.eclipse.jgit.revwalk.PendingGenerator.next(PendingGenerator.java:141)
        at org.eclipse.jgit.revwalk.BlockRevQueue.<init>(BlockRevQueue.java:65)
        at org.eclipse.jgit.revwalk.FIFORevQueue.<init>(FIFORevQueue.java:64)
        at org.eclipse.jgit.revwalk.StartGenerator.next(StartGenerator.java:151)
        at org.eclipse.jgit.revwalk.RevWalk.next(RevWalk.java:420)
        at org.eclipse.jgit.revplot.PlotWalk.next(PlotWalk.java:109)
        at org.eclipse.jgit.revwalk.RevCommitList.fillTo(RevCommitList.java:305)
        at org.eclipse.egit.ui.internal.history.GenerateHistoryJob.run(GenerateHistoryJob.java:70)
        - locked <7d12b0208> (a org.eclipse.egit.ui.internal.history.SWTCommitList)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Comment 1 Robin Rosenberg

2011-06-09 03:03:56 EDT

The supplied stack trace was produced by jstack. The job seems to abort and restart ad infinitum

Comment 2 Robin Rosenberg

2011-06-10 18:17:48 EDT

The supplied information had nothing to do with it. This is closer:

Slightly funny refnames can cause this.

This content of the refs directory yields the problem

refs
refs//heads
refs//heads/my
refs//heads/my/a
refs//heads/my/a/b
refs//heads/my/a/b/c
refs//heads/my/a+b

Remove the a+b file and everything is fine again.

The list above is the "find" order, ie

The sorting used in RefDirectory places a+b before a/b/c and this
causes getRefs to think the set of refs have changes over and over
again. A ref change listener then restarts the history page every
time the refs are read and the history pages does that.

Comment 3 Robin Rosenberg

2011-06-12 18:41:07 EDT

Patch posted as http://egit.eclipse.org/r/3718

Comment 4 Robin Rosenberg

2011-08-10 14:41:33 EDT

Fixed in I23377f8df00c7252bf27dbcfba5da193c5403917