gvim in Precise can't connect to ibus and takes a long time to load

Bug #987707 reported by djwong
This bug affects 27 people
Affects Status Importance Assigned to Milestone
vim (Ubuntu)

Bug Description

Hi. I have a system with Ubuntu 12.04 (updated 24 April 2012), with the Chinese language packs and the pinyin ibus system installed. The system has vim-gtk 2:7.3.429-2ubuntu2 installed on it. When I start gvim with no arguments, the window appears on the screen, but it is not responsive. After ~30 seconds of frozenness, gvim begins to respond again ... however, I can't use Ctrl-Shift to fire up the pinyin input system. If I start gvim with "gvim -f" to prevent it from forking to the background, it starts up quickly and pinyin input works.

This sounds like this is the same symptoms as bug #856779... but this is on Precise. I'll attach the strace output from the failing case.

Tags: patch
Revision history for this message
djwong (djwong) wrote :
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vim (Ubuntu):
status: New → Confirmed
Revision history for this message
Jason Conti (jconti) wrote :

This may be the ibus problem mentioned many times in bug 856779 (so this is probably a separate issue from that bug). With ibus running I experience the ~20 second pause before gvim finally starts. However, after exiting ibus, gvim will start immediately.

The real problem seems to be that without -f, the gvim process cannot connect to any dbus addresses (so I would say this bug is related to bug 776499 as well, I am seeing ** (gvim:14213): WARNING **: Unable to create Ubuntu Menu Proxy: Timeout was reached)

We seem to hang in src/ibusbus.c:ibus_bus_connect in the call to g_dbus_connection_new_for_address_sync. After modifying the code to pass the GError argument, we get the not so helpful message: Timeout was reached, the same as Ubuntu Menu Proxy.

My first thought was this was an environment issue, but the IBUS_ADDRESS seems to be correct as well as DBUS_SESSION_BUS_ADDRESS, so now I'm not sure what the problem is.

We could work around the hang in ibus by modifying ibus_bus_connect to use the asynchronous version of g_dbus_connection_new_for_address, but ibus still won't work in gvim.

Revision history for this message
Jason Conti (jconti) wrote :

After thinking about it a bit more, I figured out why we can't connect with gdbus after the fork. GDBus uses a separate thread to send and receive the message, which is only initialized once in gdbusprivate.c:_g_dbus_shared_thread_ref, guarded by the call to g_once_init_enter. After the fork, that thread is gone, so when we try to connect, no messages are sent or received, and we time out.

This can be seen by running gvim in gdb. After the fork, if you zero out shared_thread_data and ensured_classes (to avoid an abort), gvim will load right up and ibus will be working.

So I guess the only sane way to fix this on gvim's side would be to move the gtk_init_check to after the fork (although it seems gvim uses that to determine if it needs to fallback to text mode, so that may break other things).

Revision history for this message
Cif (cifvts) wrote :

I have two systems with Ubuntu 12.04, all give that error but gvim is not stuck, it works as expected

Revision history for this message
Yukihiro Nakadaira (ynkdir-deactivatedaccount) wrote :

This problem was fixed by 7.3.520.

Revision history for this message
David Barnett (mu-mind) wrote :

Here's the patch from upstream vim 7.3.520.

Any chance we could get it backported to precise?

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "ibus-init-fork.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Yukihiro Nakadaira (ynkdir-deactivatedaccount) wrote :

Patch 7.3.520 introduced another bug and it was fixed by 7.3.530.

Revision history for this message
David Barnett (mu-mind) wrote :

I tried running 7.3.530 and 7.3.520, and both fix the delay for me when I'm just opening gvim normally.

However, I'm still seeing the same symptom and error message when I run gvim from inside abominade IDE, which I've narrowed down to these steps to reproduce:
 echo -e "python <<endpython\nimport gtk\nendpython" > foo.vim
 gvim --cmd "so foo.vim"

Revision history for this message
Yukihiro Nakadaira (ynkdir-deactivatedaccount) wrote :

In my opinion, it is user's responsibility.

Revision history for this message
David Barnett (mu-mind) wrote :

You mean like the above isn't a bug?

Revision history for this message
Yukihiro Nakadaira (ynkdir-deactivatedaccount) wrote :

But I am not Vim developer.
It is better to ask to Bram or vim_dev.

Revision history for this message
Ali Afshar (aafshar) wrote :

Definite bug somewhere. It was always risky running dbus inside Python inside Vim, and I guess this has blown up now. Can anyone reproduce this with a vanilla Vim?

Revision history for this message
DaveB (david-j-barker) wrote :

Since for me the problem is just running gvim from a terminal, I have a workaround for that:
Add this to your ~/.bashrc file

function gvim() {
  nohup /usr/bin/gvim -f "$@" >& /dev/null

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.