Björn Winckler wrote: > On Wed, Feb 19, 2014 at 8:54 PM, <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
