MacVim fails to initialize properly if the last saved window position is outside of current screen

[yacoob]

I've had Macvim failed to create its first window a couple of times with:

2015-08-21 12:16:53.910 MacVim[23324:151631] Error (1000) creating CGSWindow on line 281
2015-08-21 12:16:53.912 MacVim[23324:151631] (
        0   CoreFoundation                      0x00007fff937d103c __exceptionPreprocess + 172
        1   libobjc.A.dylib                     0x00007fff90cbc76e objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff937d0eed +[NSException raise:format:] + 205
        3   AppKit                              0x00007fff98e86cc2 _NSCreateWindowWithOpaqueShape2 + 1417
        4   AppKit                              0x00007fff98e84f48 -[NSWindow _commonAwake] + 1877
        5   AppKit                              0x00007fff98f0fa19 -[NSWindow _makeKeyRegardlessOfVisibility] + 85
        6   AppKit                              0x00007fff98f0f98e -[NSWindow makeKeyAndOrderFront:] + 27
        7   MacVim                              0x000000010823481d -[MMWindowController presentWindow:] + 147
        8   Foundation                          0x00007fff9673b4eb __NSFireDelayedPerform + 364
        9   CoreFoundation                      0x00007fff937242e4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
        10  CoreFoundation                      0x00007fff93723f73 __CFRunLoopDoTimer + 1059
        11  CoreFoundation                      0x00007fff9379753d __CFRunLoopDoTimers + 301
        12  CoreFoundation                      0x00007fff936df608 __CFRunLoopRun + 2024
        13  CoreFoundation                      0x00007fff936debd8 CFRunLoopRunSpecific + 296
        14  HIToolbox                           0x00007fff8fbc656f RunCurrentEventLoopInMode + 235
        15  HIToolbox                           0x00007fff8fbc62ea ReceiveNextEventCommon + 431
        16  HIToolbox                           0x00007fff8fbc612b _BlockUntilNextEventMatchingListInModeWithFilter + 71
        17  AppKit                              0x00007fff98e738ab _DPSNextEvent + 978
        18  AppKit                              0x00007fff98e72e58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
        19  AppKit                              0x00007fff98e68af3 -[NSApplication run] + 594
        20  AppKit                              0x00007fff98de5244 NSApplicationMain + 1832
        21  libdyld.dylib                       0x00007fff8cbbd5c9 start + 1

As a result the process keeps running, but there's no UI to interact with.

I've traced it down to MacVim trying to restore its window in a place that is outside of current screen. This happens when I work on a macbook with a large external display connected, quit MacVim, disconnect the display, then try to launch MacVim again.

$ defaults read org.vim.MacVim MMTopLeftPoint
{4, 1577}
$ osascript -e 'tell application "Finder" to get bounds of window of desktop'
0, 0, 1680, 1050

Removing the setting makes MacVim happy again and allows it to initialize properly:

$ defaults delete org.vim.MacVim MMTopLeftPoint

It'd be nice if MacVim would realise this on its own and didn't fail during window creation. :)

[jpetrie]

This is interesting, because MacVim does realize this and adjust the window position. It happens in MMAppController.m:764 or so (in windowControllerWillOpen:). If the point extracted from NSUserDefaults is non-zero, MacVim attempts to find the screen containing the given point. If none is found, it fits the frame of the window to the current screen.

I can't reproduce this by forcing MMTopLeftPoint to be what your example shows, or otherwise obviously off my screen (some coordinate at like 90,000) or something. I also can't reproduce it when I repeat the steps you give (use external monitor, quit MacVim, disconnect, launch MacVim).

Does it reproduce reliably for you? Does it reproduce reliably if you run MacVim without loading your own .vimrc and plugins (mvim -u NONE)?

A quick bit of poking around for information about the error message on the top of the stack trace suggests it's a low-level thing caused, potentially, by starving the window manager for window resources. When this happens are you doing a lot of other stuff with other applications that have a ton of windows open? Seems like it would be a really difficult limit to hit unless some application was somehow leaking them in the background. Or maybe MacVim is?

[yacoob]

Before filing this bug I've bumped into this problem a couple of times over 6 last months. This time I was finally angry and determined to trace it down. After reading your update and bit of testing it looks like there's something more at play.

• I can't reliably reproduce it via the method I've described in first update - I'm guessing that's what is causing MMTopLeftPoint to be set to large value, but I can't make MacVim fail on demand in a way I've described there.
• I can blow it up most of the time by setting the second coordinate to offscreen value

More testing to follow. FWIW, I have:

set lines=999                " maximize window by default, vertical
set columns=999              " and horizontal

in my .gvimrc, but all of the testing I've done that I've described above in this update was done with calling mvim -u NONE -U NONE.

[georgesnelling]

I'm hitting this 100% of the time after installing El Capitan, meaning my macvim installation is completely hosed. I uninstalled the old version, cloned this repro and built from source today. I've tried mvim --fresh without luck. Here are the defaults:

defaults read org.vim.MacVim
{
MMCurrentPreferencePane = Advanced;
MMLastWindowClosedBehavior = 2;
MMNativeFullScreen = 0;
MMUntitledWindow = 0;
NSQuotedKeystrokeBinding = "";
NSRepeatCountBinding = "";
}

I've renamed my .vim, .viminfo, .vimrc and .gvimrc to other names and relaunched. Same problem: The macvim icon appears in the doc and the menu is active, but there is no window, and no way to create a window.

One clue that I can't figure out: if I right-click on the macvim icon in the dock, it displays a list of my most recently opened files. I can't figure out where that list is coming from: it persists between installs and reboots, and is not coming from any of my vim - related .dot files, since it still appears after they have all been renamed. I wonder if this is the same place macvim is getting its last known window location from the OS? If you know where that is please comment and I'll see if I can clear that.

Any ideas?

[jpetrie]

I can't figure out where that list is coming from:

It comes from the OS I believe; you likely have it configured to "remember the last N most-recently-used documents."

MacVim uses this or this to set up window positions. It would be interesting to know what decision path the latter is taking, since I've been unable to reproduce this (even on El Capitan) myself.

[georgesnelling]

Thanks for the reply. If I create an entirely new user account and run macvim from there everything works fine, so the build itself is ok.

In the hosed user account I tried removing ~/Library/Preferences/org.vim.MacVim.plist altogether and that did not help.

I think it's getting some unexpected value from the OS for last window position for this app for this user, but that data is stored someplace other than the dot files, and the org.vim.MacVim.plist. I'm afraid I don't know Objective C well enough to debug it better than that.

[yacoob]

@georgesnelling since two or versions of OSX or so, removing plist is no longer sufficient, as preferences are cached by a system daemon. If you want to test this, you need to rm the file and then killall cfprefsd.

[chdiza]

Alternatively: defaults delete org.vim.Macvim obviates the need to kill a daemon (according to Apple).

[georgesnelling]

Thanks everyone:

[gs] ~ $ defaults delete org.vim.MacVim
[gs] ~ $ defaults read org.vim.MacVim
2015-10-29 14:45:05.569 defaults[996:130822]
Domain /Users/gs/Library/Preferences/org.vim.MacVim does not exist
[gs] ~ $ killall cfprefsd
[gs] ~ $ killall cfprefsd
No matching processes belonging to you were found
[gs] ~ $

Then launch macvim: no window. The OS must be reading that value from some other key.

[chdiza]

Do you have some kind of third-party window manager installed, like Slate, Divvy, etc?

[georgesnelling]

Nope, completely vanilla.

[nedbat]

I can reproduce this (sometimes?). I connect a large external monitor, and then close my laptop lid, so I have only one screen, on the external monitor. I open MacVim, and position it to fill the screen. Quit MacVim. Unplug the monitor to go back to the laptop screen. Look at plutil -convert xml1 -o - org.vim.MacVim.plist, it will have MMTopLeftPoint set to something large like {217, 1408}. Now MacVim will get the stacktrace in the original description.

Deleting the property with defaults delete org.vim.MacVim MMTopLeftPoint fixes it.

BUT: sometimes the MMTopLeftPoint property isn't set? No idea why. In that case it works fine.

[nedbat]

I seem to be able to reproduce this simply by setting MMTopLeftPoint:

[:~/Library/Preferences] $ plutil -convert xml1 -o - org.vim.MacVim.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>MMAutosaveColumns</key>
    <integer>66</integer>
    <key>MMAutosaveRows</key>
    <integer>23</integer>
    <key>NSQuotedKeystrokeBinding</key>
    <string></string>
    <key>NSRepeatCountBinding</key>
    <string></string>
</dict>
</plist>
[:~/Library/Preferences] $ # MacVim launches just fine.
[:~/Library/Preferences] $ defaults write org.vim.MacVim MMTopLeftPoint '"{217,1408}"'
[:~/Library/Preferences] $ plutil -convert xml1 -o - org.vim.MacVim.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>MMAutosaveColumns</key>
    <integer>196</integer>
    <key>MMAutosaveRows</key>
    <integer>56</integer>
    <key>MMTopLeftPoint</key>
    <string>{217,1408}</string>
    <key>NSQuotedKeystrokeBinding</key>
    <string></string>
    <key>NSRepeatCountBinding</key>
    <string></string>
</dict>
</plist>
[:~/Library/Preferences] $ # MacVim won't open a window
[:~/Library/Preferences] $ defaults delete org.vim.MacVim MMTopLeftPoint
[:~/Library/Preferences] $ # MacVim opens fine.

Using MacVim 7.4 (84).

[splhack]

Good catch. However I still cannot reproduce the issue on MacBook Pro 15(The resolution setting is "Default for display") with no external monitors.

$ killall MacVim
No matching processes belonging to you were found
$ killall Vim
No matching processes belonging to you were found
$ defaults delete org.vim.MacVim
$ defaults write org.vim.MacVim MMTopLeftPoint '"{217,1408}"'
$ defaults read org.vim.MacVim MMTopLeftPoint
{217,1408}
$ plutil -convert xml1 -o - ~/Library/Preferences/org.vim.MacVim.plist|grep MMTopLeftPoint -A 1
        <key>MMTopLeftPoint</key>
        <string>{217,1408}</string>
$ /Applications/MacVim.app/Contents/MacOS/Vim -g -u NONE -U NONE

MacVim opens a window and it works well.

[nedbat]

Hmm, I wonder if somehow it is important that I have used an external monitor in the past? Too much state.... I'm on 10.10.5, btw.

[splhack]

I tried to use an external monitor, but still I can't reproduce the issue.

You can 100% reproduce it using my command lines with no external monitors?

[nedbat]

There's a factor in my init files somewhere. Using -u NONE -U NONE, it doesn't happen. I'll try to find it.

[yacoob]

FWIW, I have these in my .gvimrc:

set lines=999                " maximize window by default, vertical
set columns=999              " and horizontal

Perhaps it's the wrong value and a resize that's causing this? Sorry, can't verify this on my own atm.

[nedbat]

Create a gvimrc_bad file with this:

set lines=999 columns=999

Then:

$ defaults write ~/Library/Preferences/org.vim.MacVim MMTopLeftPoint '"{217,1408}"'
$ /Applications/MacVim.app/Contents/MacOS/Vim -g -u NONE -U gvimrc_bad

This crashes for me.

[nedbat]

@yacoob wow, your comment appeared as I was entering mine!

[yacoob]

Hm, I've actually mentioned that earlier in this bug's history too. Hehe :D

[splhack]

Still I can't reproduce it.

$ killall MacVim
$ killall Vim
$ defaults delete org.vim.MacVim
$ defaults write org.vim.MacVim MMTopLeftPoint '"{217,1408}"'
$ cat /tmp/gvimrc_bad
set lines=999 columns=999
$ /Applications/MacVim.app/Contents/MacOS/Vim -g -u NONE -U /tmp/gvimrc_bad

No crash. A maximum window opened and works well.

You guys on 10.10.5? So it seems it is the best time to upgrade your OS X 😉

[yacoob]

Yup, I'm on 10.10.5, and I'll be upgrading soon-ish. Unless MacVim requires 10.11, I still think this is a bug worth fixing :)

[splhack]

confirmed. I can reproduce the issue on 10.10.5. It never happens on 10.11.2. I recommend to update OS X to solve the issue.

[georgesnelling]

I don't have enough of a repro to reopen the issue, but I believe the issue occurred for me when running 10.11.2. Hopefully I'm wrong, and this was fixed in Apple code and we'll never see it again. But if someone out there ever hits it again using builds >= 10.11.2 know that you are not entirely alone or crazy.

[splhack]

@georgesnelling you said "Then launch macvim: no window.", not the crash. It sounds the exactly same as #109.

[georgesnelling]

Oh, you may well be right. I was messing around with docker at the time. I withdraw my skeptical comment.

[gamer7569]

Czdcyuzvjjcjl.

Sent from Outlook Mobile

On Fri, Dec 18, 2015 at 7:27 PM -0800, "Kazuki Sakamoto" notifications@github.com wrote:

Closed #66.

---

Reply to this email directly or view it on GitHub:
#66 (comment)