I have a trac 1.0.1 installation with python 2.7 on NetBSD 5 amd64, which generally works well. My main repo is svn and a second repo is git. The git repository is very large, with "git log --oneline" on master showing 19000 commits and a checkout taking up 4.3G in over 250K files.
Recently one of our users noticed that the "browse source" tab was
broken, or rather that while it worked ok, clicking on 'foogit' (as we
call the git repo associated with this Project Foo) resulted in a stack
backtrace from python. The problem was that after running git log, trac
tried to kill the git process, and in our case it had apparently already
finished. Adding the following change (thanks to Nick Goffee for python
advice) resulted in browsing working fine, although it takes 29s for the
top-level repo page to load. (Some of the directories in the repo were
last touched early on in the repo's history, 4 years and most of those
19K commits ago). I have observed backtraces from both locations.
So probably this change should be applied to trac sources, or comments
added explaining why the process must still be alive when terminate is
called.
--- PyGIT.py.~1~ 2013-01-31 19:47:41.000000000 -0500
+++ PyGIT.py 2014-03-11 12:55:05.000000000 -0400
@@ -913,7 +913,11 @@
except ValueError:
break
f.close()
- terminate(p[0])
+ # The process may or may not have finished.
+ try:
+ terminate(p[0])
+ except:
+ pass
p[0].wait()
p[:] = []
while True:
@@ -930,7 +934,10 @@
if p:
p[0].stdout.close()
- terminate(p[0])
+ try:
+ terminate(p[0])
+ except:
+ pass
p[0].wait()
def last_change(self, sha, path, historian=None):
pgp2O8GRorrVJ.pgp
Description: PGP signature
