vim-gnome freezing from any GTK event at Jaunty

[Ivan Zorin]

distribution: Ubuntu Jaunty Alpha 1
package: vim-gnome 7.2.025-2ubuntu1
bug: vim-gnome freezing from any GTK event
steps to reproduce:
1. run gvim (from terminal or from main menu)
1a. try to input or preprocess some text via internal vim commands - everything should be ok
2. try to open some gvim menu (for example, File or Syntax, but it can be any other GTK event, such like "close" dialog or something else) - in my case this action completely freeze gvim window and some other windows;

For unfreeze system, open some tty terminal, log in and run:
$ ps ax | grep gvim
to find out pid_of_gvim, and then:
$ kill -9 pid_of_gvim
after switching back for tty7, system should be unfreeze.

[Aioanei (aioanei-redhat-bugs)]

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):
7.2.13

How reproducible:
every time

Steps to Reproduce:
1.start gvim
2.
3.

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.

[Karsten (karsten-redhat-bugs)]

does gvim start with 'gvim -u NONE -U NONE' ?

[Karsten (karsten-redhat-bugs)]

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.

[Joachim (joachim-redhat-bugs)]

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.

[Joachim (joachim-redhat-bugs)]

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?

[Joachim (joachim-redhat-bugs)]

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].

[Joachim (joachim-redhat-bugs)]

Well, I meant to write "After installing F10-PR-x86_64 from scratch ..".

[Karsten (karsten-redhat-bugs)]

Have you tried to reproduce this with a newly created user ?

[Joachim (joachim-redhat-bugs)]

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.

[Karsten (karsten-redhat-bugs)]

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 ?

[Joachim (joachim-redhat-bugs)]

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 ..

[Joachim (joachim-redhat-bugs)]

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.

[Joachim (joachim-redhat-bugs)]

No improvement when building with argument

  --enable-gui=gnome2

instead of

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

In the past, the first UI choice used to enable GNOME sound effects for gvim.

[Bug (bug-redhat-bugs)]

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Joachim (joachim-redhat-bugs)]

No improvement for current "rawhide" build vim-X11-7.2.060-1.fc11.

[Joachim (joachim-redhat-bugs)]

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.

[Joachim Frieben (jfrieben)]

- I have observed the same issue for snapshot of the Ubuntu 9.04 desktop spin as of 2009-01-20.

- The same issue occurs on current Fedora 10, see

    https://bugzilla.redhat.com/show_bug.cgi?id=463908 .

  consequently, this bug should already have occured in Ubuntu 8.10 based upon GNOME 2.24.x.

- Moreover, it appears that the bug is not in VIM because vim-X11-7.2.060-1.fc10 on F10 does
  grab the mouse pointer whereas the same version vim-X11-7.2.060-1.fc9 but on F9 does not.

- NOTE: I have observed that on F10, the issue is directly related to whether "Play sound effects
  when buttons are clicked" are enabled or not. Thus if you have problems with vim-gnome as
  described above, you can try to open the system sound preferences of the GNOME desktop
  and disable "Play sound effects when ..".

- In order to release the mouse focus, it is sufficient to execute 'killall gvim'. A PID is not
  necessary.

[Joachim (joachim-redhat-bugs)]

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.

[Joachim (joachim-redhat-bugs)]

Issue also affects a live spin from "rawhide" as of 2009-02-04:

  alsa-lib-1.0.19-1.fc11.x86_64
  alsa-plugins-pulseaudio-1.0.18-2.fc11.x86_64
  alsa-utils-1.0.19-1.fc11.x86_64
  gnome-desktop-2.25.90-2.fc11.x86_64
  gnome-session-2.25.90-1.fc11.x86_64
  kernel-2.6.29-0.78.rc3.git5.fc11.x86_64
  pulseaudio-0.9.14-2.fc11.x86_64
  pulseaudio-core-libs-0.9.14-2.fc11.x86_64
  pulseaudio-esound-compat-0.9.14-2.fc11.x86_64
  pulseaudio-libs-0.9.14-2.fc11.x86_64
  pulseaudio-libs-glib2-0.9.14-2.fc11.x86_64
  pulseaudio-module-gconf-0.9.14-2.fc11.x86_64
  pulseaudio-module-x11-0.9.14-2.fc11.x86_64
  pulseaudio-utils-0.9.14-2.fc11.x86_64
  vim-X11-7.2.088-1.fc11.x86_64

[Joachim (joachim-redhat-bugs)]

Issue fixed in the latest Ubuntu 9.04 daily-live spin, see

  https://bugs.launchpad.net/bugs/308713

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.

[Joachim Frieben (jfrieben)]

Issue fixed for current daily-live spin including vim-gnome-7.2.079-1ubuntu4. I suppose it was a PA or GNOME issue but the important thing is that it is settled now.

[Joachim (joachim-redhat-bugs)]

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.

[Joachim (joachim-redhat-bugs)]

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?

[Joachim (joachim-redhat-bugs)]

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.

[Karsten (karsten-redhat-bugs)]

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...

[Joachim (joachim-redhat-bugs)]

(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.

[Joachim (joachim-redhat-bugs)]

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

[James (james-redhat-bugs)]

Looks like #488652 is a dupe of this bug, albeit with a description of the root cause of the bug.

[Bug (bug-redhat-bugs)]

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

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.