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

[djwong]

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.

[Launchpad Janitor (janitor)]

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

[Jason Conti (jconti)]

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.

[Jason Conti (jconti)]

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

[Cif (cifvts)]

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

[Yukihiro Nakadaira (ynkdir-deactivatedaccount)]

This problem was fixed by 7.3.520.

[David Barnett (mu-mind)]

Here's the patch from upstream vim 7.3.520.

Any chance we could get it backported to precise?

[Ubuntu Foundations Team Bug Bot (crichton)]

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

[Yukihiro Nakadaira (ynkdir-deactivatedaccount)]

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

[David Barnett (mu-mind)]

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"

[Yukihiro Nakadaira (ynkdir-deactivatedaccount)]

In my opinion, it is user's responsibility.

[David Barnett (mu-mind)]

You mean like the above isn't a bug?

[Yukihiro Nakadaira (ynkdir-deactivatedaccount)]

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

[Ali Afshar (aafshar)]

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?

[DaveB (david-j-barker)]

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
}