Skip to content

Ctrl-C on rebase leaves behind a stale index.lock file #338

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
orgads opened this issue Aug 31, 2015 · 7 comments
Closed

Ctrl-C on rebase leaves behind a stale index.lock file #338

orgads opened this issue Aug 31, 2015 · 7 comments
Assignees
@dscho
Labels
bug msys2 up for grabs
Milestone
v2.13.1

Comments

@orgads
Copy link

orgads commented Aug 31, 2015

It happens to me frequently that in the middle of a rebase I cancel it using Ctrl-C, and then it leaves a stale index.lock, which must be removed manually.

IIRC I had it with other operations as well, but I can't tell for sure.
@orgads
Copy link
Author

orgads commented Nov 8, 2015

Any news? This happens to me quite frequently...

@dscho
Copy link
Member

dscho commented Nov 9, 2015

Any news? This happens to me quite frequently...

I guess I do not cancel rebases, so the bug does not affect me...

To be honest, I have no idea what is really going on. I know what should be going on: Inside MinTTY, an MSys2 Bash is running. From this Bash, you call a shell script, which is handled by the same Bash via forking a new MSys2 process. This process in turn wants to fork a new process for every external executable called by the script, e.g. git.exe. Now, git.exe is not an MSys2 process, so it has no idea about signal handling or other POSIX niceties. Therefore, a POSIX wrapper process is started that in turn runs git.exe and tries to handle signals for it, e.g. accepting a SIGTERM and killing the process.

And here is where things went wrong in my tests earlier this year: git.exe would be killed, but none of its child processes. One symptom of this behavior was that quitting the pager of git log would not stop the git-log.exe process at all.

To remedy this, I implemented this patch series that makes sure that children of non-MSys2 processes are killed when a SIGTERM was received.

My guess is that we would need to do something different there, such as sending a different kind of "signal" via TerminateProcess() to give Git a chance to run its signal handler to remove the temporary files.

Hopefully this provides you with enough information to go further.

@dscho
Copy link
Member

dscho commented Nov 12, 2015

To be clear: I have unfortunately no time to spend on this ticket in the foreseeable future.

@dscho
Copy link
Member

dscho commented Apr 2, 2016

@orgads would you have time to drive this issue a bit? I think that I know what is going on, but I am too short on time to investigate.

@sxlijin
Copy link

sxlijin commented Nov 25, 2016

I can't reproduce it; am on Win7 x64:

git version 2.10.1.windows.1
sizeof-long: 4
machine: x86_64

@dscho dscho mentioned this issue May 18, 2017
Merged
@dscho
Copy link
Member

dscho commented May 19, 2017

@orgads this has been tough to fix, and it would not have happened without @whoisj's excellent guidance. The newest snapshot should fix this issue. Please test.

dscho added a commit to git-for-windows/build-extra that referenced this issue May 19, 2017
@dscho
Mention Bug Fix in release notes
8853228 
When interrupting Git processes in Git Bash by
pressing Ctrl+C, [Git now removes `.lock` files as
designed](git-for-windows/msys2-runtime#15)
([accompanying Git
PR](git-for-windows/git#1170); this should also
fix [issue #338](git-for-windows/git#338)).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@orgads
Copy link
Author

orgads commented May 21, 2017

Looks good. Thanks!

@dscho dscho self-assigned this May 22, 2017
@dscho dscho added this to the v2.13.0(1) milestone May 22, 2017
@dscho dscho closed this as completed May 22, 2017
@dscho dscho mentioned this issue Sep 26, 2017
Closed
1 task
benpeart pushed a commit that referenced this issue Jan 18, 2018
@dscho
Merge tag 'v2.13.1.windows.1' into users/johasc/gvfs/merge-2.13.1
9330293 
Git for Windows v2.13.1

Changes since Git for Windows v2.13.0 (May 10th 2017)

New Features

  * Comes with Git v2.13.1.
  * Comes with Git Credential Manager v1.10.0.
  * Comes with OpenSSH 7.5p1.
  * Comes with Git Flow v1.11.0.
  * Comes with Git LFS v2.1.1.
  * Git now uses the flag introduced with Windows 10 Creators Update to
    create symbolic links without requiring elevated privileges in
    Developer Mode.

Bug Fixes

  * The documentation of Git for Windows' several config files was
    improved.
  * When interrupting Git processes in Git Bash by pressing Ctrl+C, Git
    now removes .lock files as designed (accompanying Git PR; this
    should also fix issue #338).
  * git status -uno now treats submodules in ignored directories
    correctly.
  * The fscache feature no longer slows down git commit -m <message> in
    large worktrees.
  * Executing git.exe in Git Bash when the current working directory is
    a UNC path now works as expected.
  * Staging/unstaging multiple files in Git GUI via Ctrl+C now works.
  * When hitting Ctrl+T in Git GUI to stage files, but the file list is
    empty, Git GUI no longer shows an exception window.

This is an "evil merge", i.e. it introduces two changes that were on
neither side of the commit history:

- t7061 added a test case in upstream that adds a submodule, and the test
  case GVFS Git added needed to be adjusted to expect that submodule now.

- t0025 was removed upstream, but we added a test case in GVFS Git. This
  test case was moved and adjusted to run first thing in t0027 (which is
  the legal successor to t0025).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dscho dscho

Labels
bug msys2 up for grabs
Projects
None yet
Milestone
v2.13.1
Development

No branches or pull requests
3 participants
@dscho @sxlijin @orgads