MacVim bug in Mavericks

377 views
Skip to first unread message

dv1...@wayne.edu

unread,
Feb 19, 2014, 2:54:56 PM2/19/14
to vim...@googlegroups.com
I think there's a bug in MacVim that manifests when using its GUI form
but not when one calls it in the console. This bug doesn't affect
BramVim either. I have never seen this until Mavericks.

There is more than one way to reproduce it. I'm going to include at
least two such ways because it might help shed light on the issue.

##################

To reproduce, way #1:

0. Have some file (any file) already open in a MacVim window.

1. Navigate in the terminal to some file on your system that is owned by
root and for which only root is allowed read-access. If you can't find
one, do this: touch foo; sudo chown root:wheel foo; sudo chmod go-rwx
foo.

2. Do 'sudo -K' to make sure you shouldn't be able to read foo. Do
'mvim -u NONE -U NONE foo', where 'foo' is that file.

3. Expected behavior: MacVim window appears with no contents but
'"foo" [Permission Denied]' at the bottom of the window. The MacVim
window that was already open remains untouched.

4. Actual behavior: MacVim instantly quits; all its windows are gone and
the green diamond vanishes from the Dock. No opportunity to save
unsaved documents is presented.

5. Observation: Console.app contains the following:

p Vim[34269]: -[MMBackend(Private) connectionDidDie:]@2315: Main connection was lost before process had a chance to terminate; preserving swap files.

6. Observation #2: The "Expected Behavior" is exhibited by MacVim if one
uses the console form (the Vim binary inside the app bundle, which I
call by pointing an executable bash script at its path). It's also
exhibited by BramVim.

7. Observation #4: I have never observed this kind of behavior on any
OS prior to Mavericks. I will try to follow the above reproduction
procedures on Tiger and Leopard and Lion later tonight. I predict,
however, that I will see the Expected Behavior. I know I've seen
"Permission Denied" in MacVim a million times before.

8. Observation #5: Occasionally the Expected Behavior will almost
occur, if I keep doing step 2 over and over. By "almost" I mean that I
get a MacVim window with "[Permission Denied]" down below, the other
windows don't quit, but the terminal spews forth (and Console.app
reports):

MacVim[43957:303] Metadata.framework [Error]: void _MDItemMarkAsUsedForPath(CFStringRef): was called with a NULL path

Quitting MacVim and starting fresh will restore the behavior of step 4.

Step 0 is of course not necessary to generate the buggy behavior, but it
helps for illustrative purposes.

##################

To reproduce: way #2:

0. As before.

1. Create a symlink to a non-existent target: ln -s "fooblyfoobly
dummy".

2. Navigate in the terminal to the workind dir. Then do "mvim -u NONE
-U NONE dummy".

3. Expected behavior: New MacVim window with empty contents and '"dummy"
[New File]' at the bottom.

4. Actual behavior: as in step 4 above. All other observations are the
same.

Observation: Doing "mvim" rather than double-clicking in the Finder is
necessary to show the bug, because otherwise the Finder will detect that
there's no underlying file and short-circuit things before handing off
to MacVim.

##################

I sure hope this has nothing to do with AppNap. I have been seeing
strange delays in MacVim, only on Mavericks, only in GUI mode, that
shouldn't be happening. I just can't even begin to reliably reproduce
them for a report (which itself is some evidence that it's AppNap
related).

Björn Winckler

unread,
Feb 28, 2014, 12:59:28 PM2/28/14
to vim...@googlegroups.com
I cannot reproduce the crash you describe, but I do see the error

Metadata.framework [Error]: void
_MDItemMarkAsUsedForPath(CFStringRef): was called with a NULL path

It's a private API related to file metadata, but I don't know what it means.

Björn
Reply all
Reply to author
Forward
0 new messages