This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 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
> gvim.exe.stackdump
>      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
config file?

Thomas Shanks

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]