On Tue, Jun 22, 2010 at 9:13 PM, Thomas Shanks <thomas.sha...@gmail.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 > 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
