You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that the "git bug rm" command hangs on my machine when I try to remove a test bug that I created....
I think I have tracked it down to the lock taking on line 502 of "cache/repo_cache_bug.go".
I don't know enough about the code to find the root cause at the moment......
Side question: In order to remove the bug I removed the branch from the "refs/bugs" folder and then deleted the git-bug cache....Should that work?
Running this locally (Debian Bullseye Linux) results in the hanging CLI as noted above and CTRL-C doesn't terminate the hung state. Running this using Go test running and the new testEnv created as part of https://github.com/selesy/git-bug/tree/fix/778-git-bug-rm-broken allows the supervising Go routine to terminate the operation on timeout and return each Go routine's state. Here's the output of the test runner when that timeout occurs:
@MichaelMure - This appears to be failing because RepoCache.RemoveBug() grabs a read-lock when calling RepoCache.ResolveBugPrefix() but the underlying code called from that method already locks/unlocks the cache as needed. Removing the RLock on repo_cache_bug.go:502 does indeed solve the problem but I'd like a second set of eyes to verify that there is already sufficient locking when resolving the bug prefix.
Also, pretty cool that you are writing test for the commands. It was the intention when coming up with that code structure for commands, but I never ended up actually writing them :-)
It was pretty trivial to reproduce this issue manually, but writing tests is a great way to intimately learn the code. There are a couple changes related to making the command package more testable and there will probably be a few more required to cover other parts of the code (e.g. the interactive version of add and user create commands will need to redirect stdin along with something like send/expect helpers.)
Activity
MichaelMure commentedon May 3, 2022
Yes that's enough to do that manually.
What error did you get?
DarthRubik commentedon May 4, 2022
I don't get an error it just hangs forever
smoyer64 commentedon May 27, 2022
@MichaelMure - I've confirmed this issue on my local machine and will have a failing test for it tomorrow. If you'd like, you can assign this to me.
smoyer64 commentedon May 28, 2022
Running this locally (Debian Bullseye Linux) results in the hanging CLI as noted above and CTRL-C doesn't terminate the hung state. Running this using Go test running and the new
testEnvcreated as part of https://github.com/selesy/git-bug/tree/fix/778-git-bug-rm-broken allows the supervising Go routine to terminate the operation on timeout and return each Go routine's state. Here's the output of the test runner when that timeout occurs:smoyer64 commentedon May 28, 2022
@MichaelMure - This appears to be failing because
RepoCache.RemoveBug()grabs a read-lock when callingRepoCache.ResolveBugPrefix()but the underlying code called from that method already locks/unlocks the cache as needed. Removing theRLockonrepo_cache_bug.go:502does indeed solve the problem but I'd like a second set of eyes to verify that there is already sufficient locking when resolving the bug prefix.MichaelMure commentedon May 31, 2022
@smoyer64 I had a look, that sounds correct. In addition, other calls to
ResolveBugPrefixdon't lock that mutex so that's very likely the issue.MichaelMure commentedon May 31, 2022
Also, pretty cool that you are writing test for the commands. It was the intention when coming up with that code structure for commands, but I never ended up actually writing them :-)
smoyer64 commentedon Jun 1, 2022
@MichaelMure - PR submitted!
It was pretty trivial to reproduce this issue manually, but writing tests is a great way to intimately learn the code. There are a couple changes related to making the
commandpackage more testable and there will probably be a few more required to cover other parts of the code (e.g. the interactive version ofaddanduser createcommands will need to redirectstdinalong with something like send/expect helpers.)