From 5d370fdfece807afea55564a0f63f740ee49805c Mon Sep 17 00:00:00 2001 From: goglu6 Date: Fri, 17 Jan 2025 06:29:39 +0000 Subject: [PATCH] --- .../Unlock_filter_seems_to_deadlock_for_huge_worktree.mdwn | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/bugs/Unlock_filter_seems_to_deadlock_for_huge_worktree.mdwn b/doc/bugs/Unlock_filter_seems_to_deadlock_for_huge_worktree.mdwn index e6ba8e5bb1..e4d448f828 100644 --- a/doc/bugs/Unlock_filter_seems_to_deadlock_for_huge_worktree.mdwn +++ b/doc/bugs/Unlock_filter_seems_to_deadlock_for_huge_worktree.mdwn @@ -5,11 +5,13 @@ I wanted to unlock all those files from that branch on a machine, so I tried to Sadly, the command do not seems to finish, ever. Executing the command with debug from a clone(to avoid interacting with the broken index from the first), it seems to deadlock after executing between 10000 and 20000 "thawing" processes when executing the filter-process logic over the files in the worktree. -The problems seems to be reproducible with any repository with a lot of files in the worktree as far as I can tell, independant of file size. +The problem seems to be reproducible with any repository with a lot of files in the worktree as far as I can tell, independant of file size. -The infinite loop make higher-level commands like git annex sync also deadlock when checkout-ing the unlocked branch for any reason. +The deadlock described makes higher-level commands like git annex sync also block indefinitely when checkout-ing the unlocked branch for any reason. Also, because the filtering is not completely applied, the index is pretty scrambled, its easier to clone the repo and move the annex than fix it, for me at least. +I call the behavior "deadlock" due to the absence of outpout and low cpu usage on the process when in that state. This seems to indicate some kind of multiprocessing deadlock to me. + ### What steps will reproduce the problem? Here is a minimum set of bash commands that generate the deadlock on my end: