MacVim bug in Mavericks

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

MacVim bug in Mavericks

dv1445
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).

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: MacVim bug in Mavericks

Björn Winckler
On Wed, Feb 19, 2014 at 8:54 PM,  <[hidden email]> 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.

Björn

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: MacVim bug in Mavericks

Charles
In reply to this post by dv1445
Björn Winckler wrote:
> On Wed, Feb 19, 2014 at 8:54 PM,  <[hidden email]> 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



--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.