Description of problem: gvim(1) goes into a strange mode where it reacts to keystrokes with a great delay. The effect is similar to what a heavily overloaded system would produce, but there's nothing in the display of top(1). This happens infrequently, and looks like it only happens if user moves the cursor up (so that the whole screen goes blue). If actual maximization happens or the cursor is returned harmlessly down, seems not to matter. Version-Release number of selected component (if applicable): gnome-shell-3.0.2-4.fc15.x86_64 mutter-3.0.2.1-1.fc15.x86_64 vim-X11-7.3.138-1.fc15.x86_64 xorg-x11-server-Xorg-1.10.3-1.fc15.x86_64 xorg-x11-drv-intel-2.15.0-5.fc15.x86_64 How reproducible: Not often happens (a few times a day). Difficult to reproduce. Steps to Reproduce: 1. launch gvim 2. grab title, move up until screen goes blue 3. type something - no need to go into input mode; even keys hjkl will exhibit the delay if bug occurs Actual results: gvim becomes unusable Expected results: gvim continues to work normally Additional info: Using gnome-shell as a catch-all component, but really I have no clue what fails.
Could be ibus related. But I think to debug this, we'd need more data. Try attaching say strace to: 1) gvim 2) gnome-terminal 3) mutter The key event is going to go from kernel -> X -> mutter -> X -> gnome-terminal -> kernel pty -> gvim in the basic case. When ibus is involved it's a lot more complex. Knowing where things get slow will help.
So the blue thing by the way is a maximization hint. When you say "actual maximization" you mean say right clicking on the window title and "Maximize"? Does the blue go away for you?
I mean that if I see the blue and move cursor back so it does not maximize, then the actual maximization does not occur. The ibus is a good idea. I also see messages like these: (gvim:30841): IBUS-WARNING **: Create input context failed: Timeout was reached. These messages are not related to slow-downs, but suggestive. Also, when ibus engages for the first time, it spews a NUL character into the terminal for some reason. Clearly needs a lot of fixing. I'm setting needinfo on the bug, will reset it when I catch the strace.
Created attachment 516387 [details] 727385.gvim.1.strace
Weird, but there's no mutter process. Secondly, gvim does not use gnome-terminal, because it's an X application. Sorry, forgot to take lsof of gvim.
I have had a case when I started gvim and it got into the slow mode, then the message "(gvim:29010): IBUS-WARNING **: Create input context failed: Timeout was reached." appeared and it went back to normal. Changing the component to ibus.
The maximization turned out to be a red herring. The issue is just something that happens completely randomle on application startup.
Workaround is to run 'gvim -f' instead of gvim.
Pete, one thing that complicates this issue is ibus only runs in certain locales - in particular it doesn't run by default in English. This is something we need to fix, since as we all know as a general rule - if it's not the default, it's going to be broken. fujiwara - Is the problem that vim fork()s after initializing gtk? ...looks for vim sources... OH MY GOD WHAT IS GOING ON IN THIS PACKAGE? *two hundred and fifty patches*??? The .desktop file still isn't upstream?
Ok yes, I can confirm that the GNOME/GTK+ stack does not support calling fork() without a corresponding exec() after it's initialized. However, we should be able to do the fork() *before* we call gtk_init().
I also confirmed this problem can be fixed if fork() is called before termcapinit() in gui.c:gui_start(). termcapinit() calls gui_mch_init().
fujiwara do you have a patch? I started on one but it's messy.
Can someone with the requisite contacts look at getting any attention from the upstream vim developers?
Created attachment 519600 [details] Patch for vim/src/gui.c and vim/src/gui_gtk_x11.c I attached the tentative patch to fix the bug.
I see the same problem in F15 as well: When starting gvim, all keyboard inputs are delay for a couple of seconds. Additionally the following output is printed repeatedly on the command line: (gvim:3700): IBUS-WARNING **: Process Key Event failed: Timeout was reached. version: vim-X11.i686 2:7.3.289-1.fc15 I can confirm: - the workaround (starting gvim via "gvim -f") works - the attached patch fixes the problem Most likely this bug report and https://bugzilla.redhat.com/show_bug.cgi?id=673438 described exactly the same issue.
I can confirm the patch from fujiwara fixes the problem.
vim-7.3.315-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc14
vim-7.3.315-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc15
vim-7.3.315-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc16
Package vim-7.3.315-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing vim-7.3.315-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc16 then log in and leave karma (feedback).
vim-7.3.315-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
vim-7.3.315-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
vim-7.3.315-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
The problem described by Pete Zaitcev is still there, and it does occur when editing a file with vim in a terminal window. The symptoms are very similar to the ones described by Pete Zeitcev: 1) vim often responds with a delay of 2-3 seconds to navigation keystrokes (e.g., keeping pressed the right or left arrow keys may result in the cursor stopping moving after a few step, and then, after a 2-3 seconds delay, jumping abruptly to the end position, skipping all the intermediate ositions 2) using :w to write down the file often causes a similar 2-3 seconds delay. The described behaviour is in fact very common, what is really striking, it happens even when editing files of a tiny size, having no more than a few lines and a few hundred characters. An overall impression, when such events occur, is as if CPU/Memory are heavily overloaded. I didn't notice anything suspect when I tried to monitor CPU/Memory with the top command. This is similar to what Pete Zeitcev described in his bug report. The described problem occurs on a Fedora 16 system installed on a new Asus U46E notebook, equipped with a second generation i5 CPU and 8GB of RAM. I don't remember this kind of behaviour when I was last using Fedora 15 on a different machine in the Spring 2011. To test whether this behavior depends on the desktop environment, I tested it also in fluxbox. It certainly occurs in Fluxbox and when I edit a file with vim in terminals other than gnome-terminal, e.g., lilyterm. Besides vim, I haven't noticed any other application in a default Fedora 16 installation that behaves in the similar sluggish, unresponsive, way. The vim packages I have installed: vim-common-7.3.315-1.fc16.x86_64 vim-enhanced-7.3.315-1.fc16.x86_64 vim-minimal-7.3.315-1.fc16.x86_64 vim-X11-7.3.315-1.fc16.x86_64 vim-filesystem-7.3.315-1.fc16.x86_64 Only vim-X11-7.3.315-1.fc16.x86_64, I think, I installed myself, the remaining vim packages were installed by the anaconda installer.