Bug 536886 – Freezes on keyboard input

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 536886 - Freezes on keyboard input


Summary:	Freezes on keyboard input


Status:	RESOLVED OBSOLETE

Product:	gtk+
Classification:	Platform
Component:	Input Methods
Version:	2.12.x
Hardware:	Other Linux

Importance:	Normal major
Target Milestone:	---
Assigned To:	Hidetoshi Tajima
QA Contact:	gtk-bugs

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2008-06-05 20:52 UTC by Lionel Elie Mamane
Modified:	2018-02-10 03:42 UTC

See Also:
GNOME target:	---
GNOME version:	2.21/2.22

Description Lionel Elie Mamane 2008-06-05 20:52:20 UTC

Self-compiled SVN trunk r6365 and r6271 on different machines. On both machines, ekiga freezes as soon as it gets a keyboard event. Copy/paste (with middle mouse button) and driving the UI by mouse work fine.

Freeze = stops responding to stimuli, stops updating / refreshing / redrawing the window, except the video; if a call is already established, it continues (audio+video) OK. Just the UI is completely frozen.

Comment 1 Damien Sandras 2008-06-05 21:15:22 UTC

Can you give more information ?

Does that happen with no video preview ?

Looks strange...

Comment 2 Lionel Elie Mamane 2008-06-05 22:44:05 UTC

Yes, it happens with no video preview. I kinda had no idea what "more information" was relevant. It is pretty straightforward: run ekiga, press any key any time it has key focus (even only "alt"), the UI freezes. Every time.

It happens whether a call is happening or not. At the end of this message, a backtrace when the UI is frozen. Hmm... This backtrace makes me want to try to use a different GTK Input Method... I normally have the GTK_IM_MODULE environment variable set to xim... Let's try unsetting it... Yes, then the problem disappears. With my locale, the default is cedilla. The problem does not appear with GTK_IM_MODULE=cyrillic_translit, or am_et or inuktut. It seems to be specific to xim. It goes without saying that my whole Gnome environment runs OK with xim, so there must be *something* that ekiga does differently than the others (whether it exposes a bug in gtk+ or is a bug in ekiga is another story...).

The backtrace:
Program received signal SIGINT, Interrupt.
0x00002ab8e7716384 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt

+ Trace 199688

#0 __lll_lock_wait
from /lib/libpthread.so.0
#1 _L_lock_102
from /lib/libpthread.so.0
#2 pthread_mutex_lock
from /lib/libpthread.so.0
#3 ??
from /usr/lib/libX11.so.6
#4 XkbGetUpdatedMap
from /usr/lib/libX11.so.6
#5 XkbGetMap
from /usr/lib/libX11.so.6
#6 ??
from /usr/lib/libX11.so.6
#7 XkbLookupKeySym
from /usr/lib/libX11.so.6
#8 XLookupString
from /usr/lib/libX11.so.6
#9 _XimLocalFilter
from /usr/lib/libX11.so.6
#10 XFilterEvent
from /usr/lib/libX11.so.6
#11 gtk_im_context_xim_filter_keypress
at /build/buildd/gtk+2.0-2.12.10/modules/input/gtkimcontextxim.c line 742
#12 gtk_entry_key_press
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkentry.c line 2042
#13 _gtk_marshal_BOOLEAN__BOXED
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkmarshalers.c line 84
#14 IA__g_closure_invoke
at /tmp/buildd/glib2.0-2.16.3/gobject/gclosure.c line 490
#15 signal_emit_unlocked_R
at /tmp/buildd/glib2.0-2.16.3/gobject/gsignal.c line 2478
#16 IA__g_signal_emit_valist
at /tmp/buildd/glib2.0-2.16.3/gobject/gsignal.c line 2209
#17 IA__g_signal_emit
at /tmp/buildd/glib2.0-2.16.3/gobject/gsignal.c line 2243
#18 gtk_widget_event_internal
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkwidget.c line 4678
#19 IA__gtk_window_propagate_key_event
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkwindow.c line 4936
#20 gtk_window_key_press_event
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkwindow.c line 4966
#21 _gtk_marshal_BOOLEAN__BOXED
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkmarshalers.c line 84
#22 IA__g_closure_invoke
at /tmp/buildd/glib2.0-2.16.3/gobject/gclosure.c line 490
#23 signal_emit_unlocked_R
at /tmp/buildd/glib2.0-2.16.3/gobject/gsignal.c line 2478
#24 IA__g_signal_emit_valist
at /tmp/buildd/glib2.0-2.16.3/gobject/gsignal.c line 2209
#25 IA__g_signal_emit
at /tmp/buildd/glib2.0-2.16.3/gobject/gsignal.c line 2243
#26 gtk_widget_event_internal
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkwidget.c line 4678
#27 IA__gtk_propagate_event
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkmain.c line 2310
#28 IA__gtk_main_do_event
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkmain.c line 1556
#29 gdk_event_dispatch
at /build/buildd/gtk+2.0-2.12.10/gdk/x11/gdkevents-x11.c line 2351
#30 IA__g_main_context_dispatch
at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c line 2009
#31 g_main_context_iterate
at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c line 2642
#32 IA__g_main_loop_run
at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c line 2850
#33 IA__gtk_main
at /build/buildd/gtk+2.0-2.12.10/gtk/gtkmain.c line 1163
#34 main
at gui/main.cpp line 4431

Comment 3 Damien Sandras 2008-06-07 11:56:28 UTC

It should be transparent to user programs anyway. Assigning to GTK+ component.

Comment 4 André Klapper 2012-01-12 18:58:27 UTC

Lionel: Does this problem still happen in a recent GTK+ version (such as 3.2 or 2.24)? If yes, which version, and which distribution do you use?

Note to myself: Bug 489200 is a bit similar.

Comment 5 Lionel Elie Mamane 2012-01-12 20:16:54 UTC

It stopped happening at some point in the past. Whether this is due to a change in Ekiga or in GTK+, I don't know.

Comment 6 Matthias Clasen 2018-02-10 03:42:15 UTC

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.