reproduced

This commit is contained in:
Joey Hess 2018-08-28 12:35:15 -04:00
parent ebdb17cda7
commit 3a71f3a4a9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 18 additions and 9 deletions

View file

@ -78,4 +78,4 @@ operating system: linux x86_64
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
[[!meta title="v6 git annex add -J crash due to index somehow getting locked"]]
[[!meta title="git annex add -J crash due to index somehow getting locked"]]

View file

@ -3,14 +3,23 @@
subject="""comment 1"""
date="2018-08-28T16:16:03Z"
content="""
Does the .git/index.lock file still exist now that git-annex has exited?
Reproduced by creating 10000 files and running
`git -c annex.queuesize=100 annex add -J8`
Can you provide a log with --debug of the git-annex add command?
Can trim it to only the lines containing xargs.
Apparently it runs two concurrent git adds
when flushing the queue in some circumstances.
The smaller queue size must make it easier to reproduce;
without it all 10000 files get added ok here.
I am pretty sure git-annex only runs one git add at a time, no matter how
many jobs you configure. It seems quite likely that some other git command
was operating in the repository at the same time and locked the index,
or like the error message says, git may have somehow crashed and left
the index.lock behind.
It's not specific to v6 at all.
Hmm, worker threads don't actually get separate
Annex.repoqueue; a single queue is inherited
from the parent. Two worker threads could try
to flush the shared queue at the same time.
Since the queue updates are also done non-atomically,
which looks susceptable to races too,
I think each thread needs to get its own queue, but
only one thread ought to be allowed to flush its queue at a time.
"""]]