search

ibus / ibus

Intelligent Input Bus for Linux/Unix
https://github.com/ibus/ibus/wiki
GNU Lesser General Public License v2.1
877 stars 180 forks source link

Possible crash inside im-ibus.so #970

Closed fujiwarat closed 9 years ago

fujiwarat commented 9 years ago 
What version of the product are you using? On what operating system?
OS (Linux distributions, UNIX or ...): Ubuntu Lucid, Chrome OS
Architecture (i386, x86_64): x86_64
IBus version: git tot
Input method name and version: any
dbus version: 1.2.16-2ubuntu4
gtk version (if bug is about gtk applications): 2.20.1-1ubuntu1

What steps will reproduce the problem?

1. start ibus-daemon
2. start gedit
3. restart ibus-daemon during typing something using ibus

What is the expected output? 

gedit does not crash. After ibus-daemon restarts, you can use ibus from gedit again.

What do you see instead?

gedit crashes with signal 11 (SIGSEGV).

Please provide any additional information below.

It's a bit hard to reproduce since it's a kind of race condition bug. I guess the easiest
way to reproduce the issue is as follows:

1. open xterm and type:

$ while true ; do ibus-daemon & sleep 5; killall ibus-daemon ; sleep 1  ; done

2. open another xterm and start gedit under gdb:

$ gdb gedit

3. on gedit, hold down Ctrl and Space (the IME hot-key) for a few minutes. IME should
turn on and off very quickly.
4. After 1-2 minutes, you should get the following backtrace:

(gdb) r

(gedit:9363): GLib-GObject-WARNING **: instance of invalid non-instantiatable type
`(null)'

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe90388a3 in ibus_connection_read_write_dispatch () from /usr/lib/libibus.so.2
(gdb) bt
#0  0x00007fffe90388a3 in ibus_connection_read_write_dispatch () from /usr/lib/libibus.so.2
#1  0x00007fffe904424d in ibus_input_context_process_key_event () from /usr/lib/libibus.so.2
#2  0x00007fffe926b9b7 in ?? () from /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so
#3  0x00007ffff724b5c4 in gtk_invoke_key_snoopers (event=0x74b570) at /build/buildd/gtk+2.0-2.20.1/gtk/gtkmain.c:1959
#4  IA__gtk_main_do_event (event=0x74b570) at /build/buildd/gtk+2.0-2.20.1/gtk/gtkmain.c:1615
#5  0x00007ffff6ebf86c in gdk_event_dispatch (source=<value optimized out>, callback=<value
optimized out>, user_data=<value optimized out>)
    at /build/buildd/gtk+2.0-2.20.1/gdk/x11/gdkevents-x11.c:2372
#6  0x00007ffff59b58c2 in g_main_dispatch (context=0x6ebfb0) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:1960
#7  IA__g_main_context_dispatch (context=0x6ebfb0) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:2513
#8  0x00007ffff59b9748 in g_main_context_iterate (context=0x6ebfb0, block=<value optimized
out>, dispatch=<value optimized out>, self=<value optimized out>)
    at /build/buildd/glib2.0-2.24.1/glib/gmain.c:2591
#9  0x00007ffff59b9c55 in IA__g_main_loop_run (loop=0xa39570) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:2799
#10 0x00007ffff724bb27 in IA__gtk_main () at /build/buildd/gtk+2.0-2.20.1/gtk/gtkmain.c:1219
#11 0x000000000042bba5 in main ()

Original issue reported on code.google.com by yusukes@chromium.org on 2010-06-04 01:01:19

fujiwarat commented 9 years ago 
A colleague of mine (zork@chromium.org, please add him to cc:) figured out that there
seems to be a ref-counting issue in the ibus_input_context_process_key_event() function.
It seems that if the connection to ibus-daemon is lost inside the while-loop, the ref
count of the |connection| object immediately drops to zero?

> while (!ibus_pending_call_get_completed (pending)) {
>   ibus_connection_read_write_dispatch (connection, -1);
> }

Here is an interim patch for the issue, fyi.
http://git.chromium.org/cgi-bin/gitweb.cgi?p=ibus.git;a=commit;h=20500aae5359580f7c6b8b4b7643a101b3087e5a

Original issue reported on code.google.com by yusukes@chromium.org on 2010-06-04 01:07:16

fujiwarat commented 9 years ago 
Thanks. I will try this patch.
BTW, why ibus related libraries do not have debug symbols?

Original issue reported on code.google.com by Shawn.P.Huang on 2010-06-04 02:02:39

fujiwarat commented 9 years ago 
It's also worth noting that this loop is trying to emulate a blocking call to dbus 
without a timeout.  This can cause dbus to drop the connection, which I believe 
happens when this loop prevents other dbus messages from getting handled properly.

Original issue reported on code.google.com by zork@chromium.org on 2010-06-04 02:09:01

fujiwarat commented 9 years ago 
> BTW, why ibus related libraries do not have debug symbols?

Ah it's just because non-stripped libraries for debugging were not installed on the

Ubuntu box. Sorry for the inconvenience...

Original issue reported on code.google.com by yusukes@chromium.org on 2010-06-04 02:37:48

fujiwarat commented 9 years ago 
Ibus used g_main_context_iteration before. It has another problem.
Some time, when ibus are waiting for a reply of process_key_event, a new process-key-
event will arrive from main loop. And then the application will receive those replies

in wrong order. So I fixed it with ibus_connection_read_write_dispatch. It could stop

the mainloop, also stop the timeout. :(

Original issue reported on code.google.com by Shawn.P.Huang on 2010-06-04 02:59:07

fujiwarat commented 9 years ago 
I created a commit to make ibus_input_context_process_key_event in async mode. I think

it could fix the problem. Please test it. Thanks.

http://github.com/phuang/ibus/compare/05ed5f32b4...554e35e6dc

Original issue reported on code.google.com by Shawn.P.Huang on 2010-06-04 07:34:16

fujiwarat commented 9 years ago 
Thanks! I'm now testing it on Chromium OS.

Original issue reported on code.google.com by yusukes@chromium.org on 2010-06-04 07:52:34

fujiwarat commented 9 years ago 
http://github.com/phuang/ibus/commit/683f8d03ecbf6de5a031fdec3bc89999db857faa

Just updated the branch to set the hardward_keycode in GdkEvent correctly.

Original issue reported on code.google.com by Shawn.P.Huang on 2010-06-04 12:20:01

fujiwarat commented 9 years ago 
Hi, here are the test results:

1. Ubuntu Lucid x86_64: perfect.

I tested the latest version, 683f8d03ecbf6de5a031fdec3bc89999db857faa, using the 'while
true' script above.
Though gdb occasionally reported SIGPIPE, the im module continued working correctly
even after SIGPIPEs.

2. Chromium OS i386: almost okay. no SIGSEGV.

On Chromium OS, I tested the initial version, 554e35e6dcbee874fbcaebd81b7558ca4ff48d5d.
The patch fixed the SIGSEGV problem, but I experienced another issue on the OS.

Sometimes the backspace key (and arrow and control keys, IIRC) stopped working on a
specific text input area.
I'll try the latest version on Monday.

Thanks!

Original issue reported on code.google.com by yusukes@chromium.org on 2010-06-05 07:37:46

fujiwarat commented 9 years ago 
Thank you for testing. I found the backspace problem too. The latest commit could fix

it on my box.

Original issue reported on code.google.com by Shawn.P.Huang on 2010-06-05 08:04:31

fujiwarat commented 9 years ago 
I've just confirmed that the latest version works fine on Chromium OS too.
Thanks a lot for your quick work!

Original issue reported on code.google.com by yusukes@chromium.org on 2010-06-07 05:42:46

fujiwarat commented 9 years ago 
Thanks.

Original issue reported on code.google.com by Shawn.P.Huang on 2010-06-07 06:46:03