Bug 727385

Summary: sporadic slow key event processing
Product: [Fedora] Fedora Reporter: Pete Zaitcev <zaitcev>
Component: vimAssignee: Karsten Hopp <karsten>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: adaptee, ayurtsev, browning48ky, chkr, i18n-bugs, karsten, maxamillion, otaylor, samkraju, shawn.p.huang, tfujiwar, walters, walters, wodzicki
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: vim-7.3.315-1.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-26 23:24:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Patch for vim/src/gui.c and vim/src/gui_gtk_x11.c none

Description Pete Zaitcev 2011-08-02 02:09:32 UTC
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):


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.

Comment 1 Colin Walters 2011-08-02 13:50:01 UTC
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.

Comment 2 Colin Walters 2011-08-02 13:51:42 UTC
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?

Comment 3 Pete Zaitcev 2011-08-02 17:34:39 UTC
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.

Comment 4 Pete Zaitcev 2011-08-02 19:35:55 UTC
Created attachment 516387 [details]

Comment 5 Pete Zaitcev 2011-08-02 19:36:58 UTC
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.

Comment 6 Pete Zaitcev 2011-08-02 22:46:57 UTC
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.

Comment 7 Pete Zaitcev 2011-08-07 03:50:00 UTC
The maximization turned out to be a red herring. The issue is just something
that happens completely randomle on application startup.

Comment 8 fujiwara 2011-08-08 08:56:30 UTC
Workaround is to run 'gvim -f' instead of gvim.

Comment 9 Colin Walters 2011-08-08 12:18:13 UTC
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...


*two hundred and fifty patches*???

The .desktop file still isn't upstream?

Comment 10 Colin Walters 2011-08-08 12:26:53 UTC
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().

Comment 11 fujiwara 2011-08-09 04:17:54 UTC
I also confirmed this problem can be fixed if fork() is called before termcapinit() in gui.c:gui_start().
termcapinit() calls gui_mch_init().

Comment 12 Colin Walters 2011-08-09 09:34:36 UTC
fujiwara do you have a patch?  I started on one but it's messy.

Comment 13 Colin Walters 2011-08-22 21:43:23 UTC
Can someone with the requisite contacts look at getting any attention from the upstream vim developers?

Comment 14 fujiwara 2011-08-24 10:08:52 UTC
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.

Comment 15 Christian Krause 2011-09-21 03:14:11 UTC
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.

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.

Comment 16 Jekyll Wu 2011-09-21 04:38:43 UTC
I can confirm the patch from fujiwara fixes the problem.

Comment 17 Fedora Update System 2011-09-21 09:56:47 UTC
vim-7.3.315-1.fc14 has been submitted as an update for Fedora 14.

Comment 18 Fedora Update System 2011-09-21 09:57:36 UTC
vim-7.3.315-1.fc15 has been submitted as an update for Fedora 15.

Comment 19 Fedora Update System 2011-09-21 09:58:28 UTC
vim-7.3.315-1.fc16 has been submitted as an update for Fedora 16.

Comment 20 Fedora Update System 2011-09-21 22:14:22 UTC
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:
then log in and leave karma (feedback).

Comment 21 Fedora Update System 2011-09-26 23:24:26 UTC
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.

Comment 22 Fedora Update System 2011-09-30 18:54:13 UTC
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.

Comment 23 Fedora Update System 2011-10-02 23:01:40 UTC
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.

Comment 24 Mariusz Wodzicki 2011-11-20 04:47:41 UTC
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:


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.