This is the mail archive of the
mailing list for the Cygwin project.
vimdiff sharing violation race condition when diffing .bashrc [Was: Re: Trouble with vimdiff and strace on most recent cygwin]
- From: Thomas Shanks <thomas dot shanks at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 2 Jul 2010 16:29:41 -0400
- Subject: vimdiff sharing violation race condition when diffing .bashrc [Was: Re: Trouble with vimdiff and strace on most recent cygwin]
On Tue, Jun 22, 2010 at 9:13 PM, Thomas Shanks <email@example.com> wrote:
> $ vimdiff /etc/skel/.bashrc ~/.bashrc
> 2 files to edit
> 7 [?47h [27m [24m [0m [H [J [25;1H"/etc/skel/.bashrc" 130L, 3754C
> "~/.bashrc" [25;13H [K [25;13H135L, 3884C 1 [main] gvim 1752
> exception::handle: Exception: STATUS_ACCESS_VIOLATION
> 1164 [main] gvim 1752 open_stackdumpfile: Dumping stack trace to
> 1 [main] gvim 3760 exception::handle: Exception: STATUS_ACCESS_VIOLATION
Cygwin.dll and/or Vim devs:
It appears the file was somehow being locked by one of the vim
processes (why does starting vim take a read-lock on .bashrc?) at the
moment the other one was trying to read it.
It is, it seems, a race condition. It was failing due to sharing
violation 95% of the time, with both (!) vim processes failing to load
their required file the majority of the time. This indicates that
somehow the problem goes both ways: both the vim reading .bashrc and
the other one trying to use .bashrc can experience a sharing violation
in the same vimdiff call.
The question I have is: why does starting vimdiff use .bashrc, and why
would they both manage to experience a sharing violation when only one
is editing .bashrc?
Could this apply equally to diffing anything that vim loads during
startup, including a syntax highlighting filetype config file or other
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple