Unable to start Yavide
Opened this issue · 14 comments
The basic problem: launching yavide from Gnome or terminal, no window is displayed, ever.
I first tried this on a new install of Ubuntu 16.04, but due to repo's going missing I had to upgrade to 17.10.
After finding out Ubuntu doesn't use python2 support in their gvim, I recompiled my own from source and installed that, but despite the startup errors going away no window appears.
Figuring Ubuntu to be more trouble than it's worth, I installed the latest Fedora Core. After cloning and installing yavide, I'm met with the same issue again - launching yavide displays no Gvim window. If I launch from Gnome, I see a gvim process, but it has no windows. If I launch from terminal, no gvim process shows up.
Running with gvim -V, I found that there was an error message about xsmp save-yourself request, and found that starting with -X stopped that error, but still no window showing up.
So far, I've used two completely different distros, and gotten the exact same issue. I've not been able to find any info in your FAQ or open/closed issues regarding this. At this point I'm stumped. Is there some other distro that works? An older version perhaps? I've debugged my fair share of vim issues, but no window displaying at all just stumps me.
EDIT: I grabbed the command being used to start yavide and was able to get most of it to start up in a terminal using vim rather than gvim, but the "servername" parameter apparently isn't supported and so parts of it do not work correctly.
This may be a problem with Gnome - I've switched to Xfce4 and Yavide now launches successfully. May I ask what desktop you're using? Trying to determine if something else I've done may have caused it to start working. (Still on Fedora Core.)
Just to make sure I understood you well, running plain gvim (without Yavide involved) from terminal and/or gnome launcher works without any issues on Gnome system whether it be Ubuntu or Fedora?
I'm using Fedora 26 (Xfce) at work and Fedora 27 (Gnome) at home. I haven't experienced any such issues that you're mentioning. Although I haven't restarted Yavide in a while on my Gnome system at home I think it should still be running without such issues. I will check that once I get home from work.
In the meanwhile what you can provide me is the /tmp/YAVIDE_server.log file from the system where it fails to run and we can try to find out some more information from there.
In answer to your first question - correct. gvim by itself works fine, but when launching from YavIDE's configuration directory no window displays on two different distros (both using Gnome.)
I created a gist for the YAVIDE_server.log contents, but I thought I'd show what I've done to reproduce:
- Installed a new clean instance of Fedora 27 onto VirtualBox (2Gb ram, no 3d or 2d acceleration, all defaults)
- Ran the required
dnfcommands to install prerequisites - Ran install.sh - no errors reported
- Attempted to launch YavIDE from new shell session - gvim fails to show up, cannot CTRL+C, need to background and kill with -9
- Attempted to launch YavIDE from Gnome - gvim icon shows up, but no window does.
I'll switch over to Xfce now and see if changing nothing else results in it launching successfully.
- Installed xfce (
dnf install @xfce-desktop-environment) - Logged out, had to reboot to get Xfce to showup in the Fedora login screen
- Started yavide from the desktop icon - it works! Window shows up, a document is open, and I can see the plugins are working
At this point it looks like something isn't playing nicely with Gnome on a fresh install. Simply switching to Xfce it works fine. I had thought perhaps the VirtualBox guest additions, 3d acceleration, and compiz that I installed may have been what got it to work last night on my other system - but none of that is required, it's just what I happened to do before switching over to Xfce.
For what it's worth, here's the gist for the YAVIDE_server.log from successfully launching in Xfce - I can't spot any difference in the output.
Sounds like a really strange issue. I'll have it a go on my Gnome system at home once I get back.
Attempted to launch YavIDE from new shell session - gvim fails to show up, cannot CTRL+C, need to background and kill with -9
Do you get any details printed out at the cout in this case?
Nope, nothing printing to cout. The first post outlines how I found the command being used to start yavide, and ran that manually with -V. A lot of errors about missing images that are not related to yavide, but at the end I was getting this:
XSMP handling save-yourself request
That also turns out not to be relevant though - starting with -X stops that error, but doesn't solve the issue of the window not showing up. (gvim -X by itself still works too.)
Also I'd like to say that apart from this small Gnome issue, I'm quite liking yavide - I've customized my vim a lot but never quite to this extent, and everything just works.
Alright, now I have tried running Yavide on my home Fedora 27 (Gnome) system. I've fetched & applied the latest system updates, rebooted the machine (just in case) and re-run Yavide both from Wayland and Xorg session. Wayland is a default on Fedora. No errors or whatsoever occurred. Everything ran flawlessly.
The only difference as far as I can tell to your setup is that you are running your experiments on VMs whereas I run Linux natively. I am not sure though if that can make any difference ... I'm not sure how to go about debugging that issue further. Perhaps we can try running it with strace and see where it gets blocked? I.e. strace -ff gvim --servername yavide -f -N -u /opt/yavide/.vimrc
Also I'd like to say that apart from this small Gnome issue, I'm quite liking yavide - I've customized my vim a lot but never quite to this extent, and everything just works.
Thanks, I'm glad you like it. However, I am hoping to release a major update of this code very soon. I am basically about to make two separate modules/repositories out of the current state of Yavide, one containing a editor-agnostic, generic, core back-end implementation and the other one containing a corresponding Vim front-end implementation (just a casual Vim plugin). New design will hopefully enable more easier contributions to both back-end & front-end implementations as well as integrations to other editors. Also, people using Vim will be able to install it in a way they have been installing any other Vim plugin.
P.S. cxxd and cxxd-vim is still work-in-progress but I expect to push the stuff to the master branch very soon. I need to write some documentation and finish up some tests.
Ok, I've run strace and I think there appears to be issues connecting to the X socket - here's part of one of the logs created:
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, [124->20]) = 0
uname({sysname="Linux", nodename="localhost.localdomain", ...}) = 0
access("/home/daedalus/.Xauthority", R_OK) = -1 ENOENT (No such file or directory)
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="l\0\v\0\0\0\0\0\0\0\0\0", iov_len=12}, {iov_base="", iov_len=0}], 2) = 12
recvfrom(3, 0x55afb81bedc0, 8, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\1\0\v\0\0\0\322\5", 8, 0, NULL, NULL) = 8
recvfrom(3, "\350\247\265\0\0\0 \2\377\377\37\0\0\1\0\0\16\0\377\377\1\7\0\0 \10\377\0\0\0\0"..., 5960, 0, NULL, NULL) = 5960
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="b\0\5\0\f\0\0\0BIG-REQUESTS", iov_len=20}], 1) = 20
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\1\0\0\0\0\0\1\205\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\205\0\1\0", iov_len=4}], 1) = 4
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\2\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
File descriptor 3 appears to be trying to connect to X via socket /tmp/.X11-unix/X0, and there's also a bit about trying to open .Xauthority - when I run strace gvim by itself, I don't see a connection to an X socket, and it opens up .ICEauthority instead.
You pointed out that Wayland is the default on Fedora, so I'll try switching over to X.org - perhaps something in the configuration isn't working with Wayland.
Switching over to Gnome on X.org works - Yavide launches without issue.
So it appears that something isn't playing nice with Wayland - and the issue isn't present when launching gvim by itself, so it seems to be something in the configuration of Yavide.
Would you like me to upload the strace logs somewhere? There were several created, and it's about 84kb bzipped. Mostly they appear to be full of EPOLL and EAGAIN errors on file descriptor 3 (the X socket).
File descriptor 3 appears to be trying to connect to X via socket /tmp/.X11-unix/X0, and there's also a bit about trying to open .Xauthority - when I run strace gvim by itself, I don't see a connection to an X socket, and it opens up .ICEauthority instead.
This appears to happen because yavide runs gvim with the -f flag (-f or --nofork Foreground: Don't fork when starting GUI). Once you remove this flag, there's no mention of X11 in the strace output. To be honest, I don't think this flag is that important at all.
Can you please try running gvim -f on a Wayland system and see if the same bug exhibits? If it does, then we can be pretty sure that the issue is on the gvim side.
Also, you can check if running yavide without -f option raises the same error:
gvim --servername yavide -N -u /opt/yavide/.vimrc
My guess would be that it doesn't ...
More investigations are leaving me confused but - I have found a solution, though I don't understand why it works.
Firstly:
gvim -fworks fine by itselfgvim --servername yavide -N -u /opt/yavide/.vimrcstill fails to show a window
What does work:
gvim --servername yavide -N -u /opt/yavide/.vimrc -geometry 120x120gvim -f --servername yavide -N -u /opt/yavide/.vimrc -geometry 120x120
So for some reason on Wayland gvim doesn't seem to create a window correctly, and giving it a window size solves the issue. I can't really think why this might be, or why it only happens when starting from yavide's configuration file.
The -f flag didn't turn out to make a difference - no window displayed until I gave it the geometry command. The things that tipped me off that it might be this:
- You're running a real system and the problem isn't happening
- When I did get yavide working, the default window size vastly exceeds even my fullscreen resolution of 1920x1080, and has to be resized. This occurs every time yavide is launched, suggesting that the window setting is somewhere in the yavide configuration.
As I'm using VirtualBox's default configuration, only a small amount of VRAM is allocated (16Mb) which may be why the problem is visible on virtual machines. I installed VMWare Player and went to give that a try, but my system hard rebooted so something isn't playing nice there.
This has been interesting to delve into, and we now have causes, solutions, and workarounds so I'm pretty happy. I'm wondering if the default window size can be lowered to alleviate the issue on virtual machines.
Nice finding!
When I did get yavide working, the default window size vastly exceeds even my fullscreen resolution of 1920x1080, and has to be resized. This occurs every time yavide is launched, suggesting that the window setting is somewhere in the yavide configuration.
It is correct that yavide tries to run in a maximized window by default (at least this setting made sense to me) and it is happening here.
Would you mind checking if bug is still there if you comment this line and restart yavide (without geometry being set)?
This has been interesting to delve into, and we now have causes, solutions, and workarounds so I'm pretty happy.
Yes, I'm glad it worked out for you but I think it would be interesting to report this buggy behavior to (G)Vim bug tracker.
I'm wondering if the default window size can be lowered to alleviate the issue on virtual machines.
Let's give it a try without set lines=999 columns=999 and see if that helps.
That's exactly the cause right there - commenting out the line you specified results in yavide starting up correctly.
Steps done:
- Confirmed
yavidefrom shell and Gnome launcher no window is displayed - Modified
core/.editor.vimrcline 36, commented out - Successfully started yavide from shell
- Successfully started yavide from Gnome launcher
Throughout, the -geometry flag was not specified.
I'm thinking that you're right - I'd guess it's an issue in gvim itself. Perhaps it fails to create the window and tries to fall back to X.org - but the window creation failure was not because X.org is being used, but the window size is too large to accommodate. Falling back to X.org in this case is erroneous because Wayland is being used, hence the EAGAIN polling for the X.org socket.
I can probably put that one line into a .vimrc file and make an easily reproducible scenario for a bug report, so I'll do that over the next few days.
Great, I'm glad we identified the culprit.
I'm thinking that you're right - I'd guess it's an issue in gvim itself. Perhaps it fails to create the window and tries to fall back to X.org - but the window creation failure was not because X.org is being used, but the window size is too large to accommodate. Falling back to X.org in this case is erroneous because Wayland is being used, hence the EAGAIN polling for the X.org socket.
Yes, I suppose something along these lines is happening.
I can probably put that one line into a .vimrc file and make an easily reproducible scenario for a bug report, so I'll do that over the next few days.
Sure. Let me know if you will need any further assistance.