Re: MacVim bug in Mavericks

[Charles]

Björn Winckler wrote:
> On Wed, Feb 19, 2014 at 8:54 PM, <dv1...@wayne.edu> wrote:
>> 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).
> 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.

I can reproduce it over here on 10.9.2, following the OP's instructions.

Nothing about the error hinges on 'mvim'. Just make a symlink "foo" to a
nonexistent target. Then double-click MacVim in the Finder. Then do ":e
foo". I see the OP's "Actual behavior". I also see it if I try to do ":e
bar" on some bar that I don't have read permission for.

I'm not sure this is a genuine _crash_. There's no crash log generated.
But it does seem like a bug of some sort.

Charles