Bug 463908 - Gvim [vim-X11] becomes unresponsive after startup
Gvim [vim-X11] becomes unresponsive after startup
Product: Fedora
Classification: Fedora
Component: vim (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-09-25 06:12 EDT by Aioanei Rares
Modified: 2009-12-18 01:25 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 01:25:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aioanei Rares 2008-09-25 06:12:29 EDT
Description of problem:

After starting gvim, either from commandline or from the menu, gnome, or xfce, regardless, the window becomes unresponsive and the whole desktop becomes unresponsive also. Only issuing 'killall gvim' or 'kill -9 <pid>' from a VT gives me back my desktop.

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1.start gvim
Actual results:
The window and the desktop stop responding.

Expected results:
A useful gvim window

Additional info:
If it's indeed a gvim bug, since plain vim works great, from my little 
programming backround i'd say it's line 508 from src/gui.c [gui_create_initial_menus(root_menu)]; hope it's of any help.
Comment 1 Karsten Hopp 2008-09-29 06:25:11 EDT
does gvim start with 'gvim -u NONE -U NONE' ?
Comment 2 Karsten Hopp 2008-09-30 06:04:29 EDT
Got requested info per mail:
It does start, but the problem persists, eg if i try to use its menus(file, edit, ehlp, etc), it locks up and it
locks my desktop too, and only a killall from a VT solves it.
Comment 3 Joachim Frieben 2008-10-28 03:00:13 EDT
Same problem here on an x86_64 system in sync with the "rawhide" tree. After launching gvim, mouse input seems to be grabbed by gvim and only gets released after doing a 'killall gvim' from a virtual console.
Comment 4 Joachim Frieben 2008-11-12 02:44:33 EST
Issue does not occur on an equivalent x86 system updated to F10 + updates from Koji. Whereas the x86_64 system from comment #3 is using an ATI Radeon X800 video card, the x86 system is equipped with an Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device
This bug is -really- annoying ..
Any suggestions how to investigate further into this?
Comment 5 Joachim Frieben 2008-11-13 06:38:44 EST
After installing FC10-Snap3 x86_64 from scratch from the live CD after updating several packages of the live system including anaconda, and updating the installed system to current Koji immediately after the first boot from run level 1, gvim behaves correctly. One of the updates (which one?) did the job, so this issue should not be one anymore for F10 final [plus updates].
Comment 6 Joachim Frieben 2008-11-13 06:39:53 EST
Well, I meant to write "After installing F10-PR-x86_64 from scratch ..".
Comment 7 Karsten Hopp 2008-11-13 06:53:53 EST
Have you tried to reproduce this with a newly created user ?
Comment 8 Joachim Frieben 2008-11-13 07:30:06 EST
Yes, but I had done either this or removed all dot directories also during the last weeks after installing each F10 snapshot and preview release respectively.
But only now, the focus problem is gone ..
As pointed out in comment #4, I hadn't observed this issue on a different x86 system with the same Koji setup.
Comment 9 Karsten Hopp 2008-11-13 08:42:16 EST
There were no changes in vim which could have fixed this, I think it is save to assume that something in gtk/glib2 has caused this issue.
Does everyone agree that this bugzilla can be closed ?
Comment 10 Joachim Frieben 2008-11-13 08:45:36 EST
Hum, after another reboot [from a failed suspend], gvim has again started to
grab my mouse focus. In a 2nd essentially empty account, gvim still works as
expected. Thus, the story is not over yet ..
Comment 11 Joachim Frieben 2008-11-13 09:18:35 EST
Here is the culprit: when sound preference [System > Preferences > Hardware > Sound]

  "Play sound effects when buttons are clicked"

is enabled, then the mouse focus gets stolen by gvim as soon as one of the menu buttons is clicked. Correct behaviour can be restored in the same session by unmarking this option.
Comment 12 Joachim Frieben 2008-11-15 06:02:59 EST
No improvement when building with argument


instead of

  --enable-gtk2-check --enable-gui=gtk2 .

In the past, the first UI choice used to enable GNOME sound effects for gvim.
Comment 13 Bug Zapper 2008-11-25 22:12:55 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 14 Joachim Frieben 2008-12-02 05:40:53 EST
No improvement for current "rawhide" build vim-X11-7.2.060-1.fc11.
Comment 15 Joachim Frieben 2009-01-20 10:31:25 EST
Identical VIM versions on F9 and F10 behave differently on their respective platforms:

 F9:  vim-X11-7.2.060-1.fc9   [+] working
 F10: vim-X11-7.2.060-1.fc10  [-] broken

This suggests that the true cuplit may be somewhere in GNOME. In that case, all version >= 2.24.x are affected by this bug because a current snapshot of Ubuntu 9.04 "Jaunty Jackalope" as of 2009-01-20 using GNOME 2.25.x is also plagued by this issue.
Comment 16 Joachim Frieben 2009-01-23 08:31:06 EST
Opening a GVIM window and simply trying to close it after a while by clicking the corresponding WM button leads to the message:

  "[No Name] - GVIM2" is not responding.

Looks like a problem with the current GNOME/PA sound infrastructure.
Comment 17 Joachim Frieben 2009-02-05 14:21:51 EST
Issue also affects a live spin from "rawhide" as of 2009-02-04:

Comment 18 Joachim Frieben 2009-03-14 07:09:02 EDT
Issue fixed in the latest Ubuntu 9.04 daily-live spin, see


Can anybody confirm this progress for current "rawhide"? The Ubuntu version is vim-gnome-7.2.079-1ubuntu4 which is older than the "rawhide" version reported in comment #17 which supports the assumption that it is rather a GNOME/PA bug and not a VIM one.
Comment 19 Joachim Frieben 2009-03-27 13:41:52 EDT
Contrary to comment #18 referring to current Ubuntu 9.04, this issue is still present for current "rawhide" which features vim-X11-7.2.131-1.fc11.
Comment 20 Joachim Frieben 2009-04-24 05:29:50 EDT
It looks like this issue is gone in current "rawhide":
- alsa-lib-1.0.19-3.fc11.x86_64
- alsa-plugins-pulseaudio-1.0.18-3.fc11.x86_64
- pulseaudio-0.9.15-11.fc11.x86_64
- vim-X11-7.2.148-1.fc11.x86_64

Can anybody check against a current F10 w/updates?
Comment 21 Joachim Frieben 2009-04-25 05:54:15 EDT
For a fully updated F10 live system, the issue persists:
- alsa-lib-1.0.19-2.fc10.i386
- alsa-plugins-pulseaudio-1.0.18-2.fc10.i386
- pulseaudio-0.9.14-1.fc10.i386
- vim-X11-7.2.148-1.fc10.i386
Given the identical versions of VIM in F10 and F11, the issue is definitely not a VIM issue but rather an ALSA/PA or GNOME one.
Comment 22 Karsten Hopp 2009-05-26 04:53:07 EDT
do you have gtk-qt-engine installed ? Remove it and try again, there seem to be some issues with it that could cause such a behaviour. And add a comment here if it worked...
Comment 23 Joachim Frieben 2009-05-26 12:46:31 EDT
(In reply to comment #22)
No, I am currently running a fully updated F10 live image from a USB stick, and there is not a single QT related package installed, in particular not "gtk-qt-engine". Yet, GVIM locks up when button sound effects are enabled.
Comment 24 Joachim Frieben 2009-09-21 14:40:57 EDT
For a fully updated F10 live system, the issue persists:
- alsa-lib-1.0.21-2.fc10.i386
- alsa-plugins-pulseaudio-1.0.21-3.fc10.i386
- pulseaudio-0.9.14-3.fc10.i386
- vim-X11-7.2.148-1.fc10.i386
Comment 25 James Vega 2009-10-14 16:15:42 EDT
Looks like #488652 is a dupe of this bug, albeit with a description of the root cause of the bug.
Comment 26 Bug Zapper 2009-11-18 03:25:29 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 27 Bug Zapper 2009-12-18 01:25:59 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.