That's not obviously easier to be reproduced. which IM did you use?

I use SCIM.

$ echo $XMODIFIERS
@im=imsettings
$ imsettings-list
* 1: SCIM (recommended)
  2: nabi 
$ imsettings-info SCIM
Xinput file: /etc/X11/xinit/xinput.d/scim.conf
GTK+ immodule: scim-bridge
Qt immodule: xim
XMODIFIERS: @im=SCIM
XIM server: /usr/bin/scim 
preferences: /usr/bin/scim-setup 
auxiliary:  
Short Description: SCIM
Long Description: 
Is system default: TRUE
Is user default: TRUE
Is XIM server: FALSE

Oops, sorry. I know that :) and tried scim-anthy to see if this issue happens.
but didn't happen. so just asked if there are any easy way to reproduce that so
that it sounds like you see this issue often.

I use scim-hangul. 
Inputting only ascii character, this issue happens.

There are too much problems in XIM support and rewriting is ongoing. so disabled
XIM support in 0.101.2-3.fc10. you have to restart your desktop to apply that
change.

The issue happens again in imsettings-0.103.0-1.fc10.

With scim-hangul? sure. can you give me a debug log following up http://code.google.com/p/libgxim/wiki/HowToDebug ?

requested by Jens Petersen (#27995)

(In reply to comment #7)
> With scim-hangul? sure. can you give me a debug log following up
> http://code.google.com/p/libgxim/wiki/HowToDebug ?

Created attachment 316325 [details]
input log on emacs and xterm.

(In reply to comment #7)
> With scim-hangul? sure. 
yes. sure.

$ imsettings-list
- 1: SCIM (recommended)
  2: nabi

>can you give me a debug log following up
> http://code.google.com/p/libgxim/wiki/HowToDebug ?
Adding log file to attachment.

Thanks. I got an idea. btw I just found:

D:[dbus/event] Changing XIM server: `SCIM'->`none'

it looks like you did disable IM from im-chooser or imsettings-stop though, was it intentional?

(In reply to comment #11)
> Thanks. I got an idea. btw I just found:
> 
> D:[dbus/event] Changing XIM server: `SCIM'->`none'
> 
> it looks like you did disable IM from im-chooser or imsettings-stop though, was
> it intentional?
No.  After selecting SCIM on im-chooser, I don't modify input method setting.

(In reply to comment #12)
> No.  After selecting SCIM on im-chooser, I don't modify input method setting.

Strange. that message won't be logged unless the signal is delivered through DBus. did you press a mouse button on imsettings-applet perhaps, which has an socket icon? that do similar without changing IM setting. i.e. no wonder "-" is resulted from imsettings-list instead of "*".

Please test the package at http://tagoh.fedorapeople.org/tests/457901/. that should fixes the issue what I got from your log at least.

XIM seems to be work better now with the test packages.

Sangu, could you please have a test?

After installing new imsettings package.

backtrace in emacs
(gdb) bt
#0  0x00132416 in __kernel_vsyscall ()
#1  0x00be940d in ___newselect_nocancel () from /lib/libc.so.6
#2  0x00dc9295 in _xcb_conn_wait (c=0x9141778, cond=0x91417d8, vector=0x0, 
    count=0x0) at xcb_conn.c:340
#3  0x00dca93f in xcb_wait_for_event (c=0x9141778) at xcb_in.c:412
#4  0x00950a71 in wait_or_poll_for_event (dpy=0x9141238, wait=-1079679860)
    at xcb_io.c:100
#5  0x00950de0 in process_responses (dpy=0x9141238, wait_for_first_event=1, 
    current_error=0x0, current_request=0) at xcb_io.c:115
#6  0x00951577 in _XReadEvents (dpy=0x9141238) at xcb_io.c:212
#7  0x0092f2db in XIfEvent (dpy=0x9141238, event=0xbfa56724, 
    predicate=0x97db20 <_CheckCMEvent>, arg=0x9189b20 "L۠") at IfEvent.c:70
#8  0x0097e52a in _XimXRead (im=0x9189b20, recv_buf=0xbfa568c0 "", 
    buf_len=2048, ret_len=0xbfa567f8) at imTrX.c:448
#9  0x0097d624 in _XimReadData (im=0x9189b20, len=0xbfa5683a, 
    buf=0xbfa568c0 "", buf_size=2048) at imTransR.c:154
#10 0x0097d9e7 in _XimRead (im=0x9189b20, len=0xbfa579ca, buf=0xbfa568c0 "", 
    buf_size=2048, predicate=0x969230 <_XimSetICValuesCheck>, 
    arg=0x9120218 " ۠") at imTransR.c:231
#11 0x0096ad5c in _XimProtoSetICValues (xic=0x9120218, arg=0x0)
    at imDefIc.c:759
#12 0x009571f2 in XSetICValues (ic=0x9120218) at ICWrap.c:339
#13 0x080d8ca3 in xic_set_preeditarea (w=0x853a1c0, x=0, y=0) at xfns.c:2355
---Type <return> to continue, or q <return> to quit---
#14 0x080c7d1e in x_draw_window_cursor (w=0x853a1c0, glyph_row=0x9784d38, x=0, 
    y=0, cursor_type=0, cursor_width=-1079672496, on_p=1, active_p=1)
    at xterm.c:7402
#15 0x0806d1ff in display_and_set_cursor (w=0x853a1c0, on=1, hpos=0, vpos=0, 
    x=0, y=0) at xdisp.c:21854
#16 0x080c8e94 in x_update_window_end (w=0x853a1c0, cursor_on_p=1, 
    mouse_face_overwritten_p=0) at xterm.c:576
#17 0x08059a55 in update_window (w=0x853a1c0, force_p=0) at dispnew.c:4365
#18 0x0805ac5a in update_window_tree (w=0x853a1c0, force_p=0) at dispnew.c:3998
#19 0x0805ac43 in update_window_tree (w=0x859c478, force_p=0) at dispnew.c:3996
#20 0x0805b33d in update_frame (f=0x859a3e0, force_p=0, inhibit_hairy_id_p=0)
    at dispnew.c:3929
#21 0x08083938 in redisplay_internal (preserve_echo_area=<value optimized out>)
    at xdisp.c:11441
#22 0x0810801e in read_char (commandflag=1, nmaps=2, maps=0xbfa587e0, 
    prev_event=137661721, used_mouse_menu=0xbfa58884, end_time=0x0)
    at keyboard.c:2676
#23 0x0810a9dd in read_key_sequence (keybuf=0xbfa58934, bufsize=30, 
    prompt=137661721, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:9153
#24 0x0810c246 in command_loop_1 () at keyboard.c:1619
#25 0x081680c0 in internal_condition_case (bfun=0x810c060 <command_loop_1>, 
    handlers=137707193, hfun=0x8105720 <cmd_error>) at eval.c:1484
---Type <return> to continue, or q <return> to quit---
#26 0x08104b75 in command_loop_2 () at keyboard.c:1330
#27 0x0816819a in internal_catch (tag=137703377, 
    func=0x8104b50 <command_loop_2>, arg=137661721) at eval.c:1224
#28 0x08105579 in command_loop () at keyboard.c:1309
#29 0x0810593a in recursive_edit_1 () at keyboard.c:1007
#30 0x08105a36 in Frecursive_edit () at keyboard.c:1068
#31 0x080fc18f in main (argc=2, argv=0xbfa58fc4) at emacs.c:1770

in gedit
(gdb) bt
#0  0x00132416 in __kernel_vsyscall ()
#1  0x00d82441 in select () from /lib/libc.so.6
#2  0x071f8295 in _xcb_conn_wait (c=0x907af88, cond=0x907afe8, vector=0x0, 
    count=0x0) at xcb_conn.c:340
#3  0x071f993f in xcb_wait_for_event (c=0x907af88) at xcb_in.c:412
#4  0x00e85a71 in wait_or_poll_for_event (dpy=0x907aa48, wait=-1075065076)
    at xcb_io.c:100
#5  0x00e85de0 in process_responses (dpy=0x907aa48, wait_for_first_event=1, 
    current_error=0x0, current_request=0) at xcb_io.c:115
#6  0x00e86577 in _XReadEvents (dpy=0x907aa48) at xcb_io.c:212
#7  0x00e642db in XIfEvent (dpy=0x907aa48, event=0xbfebd1a4, 
    predicate=0xeb2b20 <_CheckCMEvent>, arg=0x940ee28 "L+�") at IfEvent.c:70
#8  0x00eb352a in _XimXRead (im=0x940ee28, recv_buf=0xbfebd354 "", 
    buf_len=2048, ret_len=0xbfebd278) at imTrX.c:448
#9  0x00eb2624 in _XimReadData (im=0x940ee28, len=0xbfebd2ba, 
    buf=0xbfebd354 "", buf_size=2048) at imTransR.c:154
#10 0x00eb29e7 in _XimRead (im=0x940ee28, len=0xbfebe45a, buf=0xbfebd354 "", 
    buf_size=2048, predicate=0xe9e110 <_XimCreateICCheck>, arg=0x0)
    at imTransR.c:231
#11 0x00e9f478 in _XimProtoCreateIC (xim=0x940ee28, arg=0x0) at imDefIc.c:1518
#12 0x00e8c2e9 in XCreateIC (im=0x940ee28) at ICWrap.c:253
#13 0x03542915 in gtk_im_context_xim_get_ic (context_xim=0x930b6e0)
    at gtkimcontextxim.c:1454
---Type <return> to continue, or q <return> to quit---
#14 0x03542c05 in gtk_im_context_xim_set_cursor_location (context=0x930b6e0, 
    area=0xbfebe594) at gtkimcontextxim.c:840
#15 0x00570910 in IA__gtk_im_context_set_cursor_location (context=0x930b6e0, 
    area=0xbfebe594) at gtkimcontext.c:374
#16 0x00570910 in IA__gtk_im_context_set_cursor_location (context=0x9432720, 
    area=0xbfebe594) at gtkimcontext.c:374
#17 0x005104c3 in update_im_cursor_location () at gtkentry.c:3263
#18 recompute_idle_func (data=0x92a3a18) at gtkentry.c:3280
#19 0x00861e8b in gdk_threads_dispatch (data=0x966cda0) at gdk.c:473
#20 0x00bf32b1 in g_idle_dispatch (source=0x9f04958, callback=0xfffffdfe, 
    user_data=0x966cda0) at gmain.c:4232
#21 0x00bf51f8 in g_main_dispatch () at gmain.c:2142
#22 IA__g_main_context_dispatch (context=0x908e238) at gmain.c:2694
#23 0x00bf88a3 in g_main_context_iterate (context=0x908e238, block=1, 
    dispatch=1, self=0x90653f0) at gmain.c:2775
#24 0x00bf8dc2 in IA__g_main_loop_run (loop=0x923adf0) at gmain.c:2983
#25 0x00587fd9 in IA__gtk_main () at gtkmain.c:1172
#26 0x08066c9c in main (argc=1, argv=0xbfebe864) at gedit.c:587

Thanks for feedback. I see where you are getting stuck into, but it really doesn't help to fix this. can you follow up the steps at comment #7 again?

Created attachment 317067 [details]
libgxim debug log

(In reply to comment #17)
> Thanks for feedback. I see where you are getting stuck into, but it really
> doesn't help to fix this. can you follow up the steps at comment #7 again?

emacs eats imsettings-applet, bug 462554 bug 462556 bug 462557 happen.

imsettings-0.104.0-1.fc10.i386
libgxim-0.2.0-1.fc10.i386
im-chooser-1.2.3-1.fc10.i386

Thanks. I roughly have an idea why emacs freezes. it's a kind of race condition issue.
The scenario looks like:

1. input something on emacs. and emacs sends XIM_FORWARD_EVENT asynchronously to XIM server through imsettings.
2. emacs also sends XIM_SET_IC_VALUES. this is a synchronous event.
3. XIM server sends back XIM_FORWARD_EVENT synchronously through imsettings.
4. XIM server receives XIM_SET_IC_VALUES but XIM server is waiting for XIM_SYNC_REPLY for XIM_FORWARD_EVENT. in the protocol definition, that says the client has to send back XIM_SYNC_REPLY when the related work to XIM_FORWARD_EVENT is finished. so XIM_SET_IC_VALUES is entering into the queue.
5. emacs receives XIM_FORWARD_EVENT with a synchrnous flag. but emacs is waiting for XIM_SET_IC_VALUES_REPLY because of a synchronous event. so it's entering into the queue.

Therefore both server side and client side is waiting for a reply of their request each other. I haven't looked at emacs's source code yet but that sounds like this issue is likely to happen without imsettings if CPU power is lower and XIM server's response is slow. which sounds like a emacs bug to me.

There may be some solutions/workarounds for this issue:

1. run SCIM with the full-synchronous mode. on this mode, all of XIM_FORWARD_EVENT will be sent synchronously. i.e. the client applications has to wait for the response for that. thus it won't send another event, which causes the race condition. this change however will slows the response of input and this affects all of applications.

2. Fix a logic in emacs to prevent the race condition.

3. Improve the performance on imsettings. this issue however may be just hidden, because the XIM protocol is an air-to-air protocol. imsettings can't back up on this. so if the client application doesn't receive and process XIM_FORWARD_EVENT before doing something with the synchronous event, this issue will be brought up again.

There may be still other solutions or workarounds. but I have no idea anything else so far.

just for update.

BTW, Sangu, have you considered using one of emacs builtin input methods for Hangul?
Does scim-hangul have big advantages over those?

(In reply to comment #20)
> BTW, Sangu, have you considered using one of emacs builtin input methods for
> Hangul?
> Does scim-hangul have big advantages over those?
No problem.  There is little difference between the two.

$ cat ~/.Xresources | grep XIM
emacs*useXIM: off
$ xrdb -m ~/.Xresources

(In reply to comment #20)
> BTW, Sangu, have you considered using one of emacs builtin input methods for
> Hangul?
> Does scim-hangul have big advantages over those?

Yes, if emacs has supported certain languages to input, that would be a 4th option and disable XIM support in emacs.

*** Bug 464439 has been marked as a duplicate of this bug. ***

I ran into this problem as well.  For now, I'm just using the "emacs*useXIM: off" Xresource to work around the problem.

It doesn't happen frequently, but I can get /usr/bin/xterm to freeze in the same way. I suspect it's also a race condition with SCIM.

Is there any easy way to disable SCIM support in xterm? (I don't think xterm pays attention to the "useXIM" resource...)

I'm trying to fake an event flow in imsettings to prevent this race condition issue now. For a workaround, putting DISABLE_IMSETTINGS=1 in .bashrc or .i18n or somewhere else would makes it harder to see this issue.

http://tagoh.fedorapeople.org/tests/452849/

Testing package for the race condition issue. I've tested i386 package and confirmed the race condition issue is gone on xterm and emacs.

For the drop-the-key issue or the always-same-result-appears issue with faster input, I've filed Bug#466657 to SCIM. FYI.

still waiting for feedbacks of testing packages :)

With these packages:

0:imsettings-0.104.99-1.fc10.x86_64
0:imsettings-libs-0.104.99-1.fc10.x86_64
0:libgxim-0.2.99-1.fc10.x86_64

...I'm not sure if I've seen xterm hang.  I also haven't been able to reproduce Emacs dropping characters.

However, Emacs still hangs frequently.  :(

As before, if I set "emacs*useXIM: off", Emacs no longer hangs.

(In reply to comment #29)
> With these packages:
> 
> 0:imsettings-0.104.99-1.fc10.x86_64
> 0:imsettings-libs-0.104.99-1.fc10.x86_64
> 0:libgxim-0.2.99-1.fc10.x86_64
> 
> ...I'm not sure if I've seen xterm hang.  I also haven't been able to reproduce
> Emacs dropping characters.
> 
> However, Emacs still hangs frequently.  :(

Thanks for your feedback. I can see that but the XIM event itself wasn't getting stuck. SCIM was sending back the key release event due to Bug#466657. which emacs doesn't take any action i.e. looks hanging up then.

Built libgxim-0.3.0-1.fc10 and imsettings-0.105.0-1.fc10.

I can still get Emacs to hang with libgxim-0.3.0-1.fc10 and imsettings-0.105.0-1.fc10.

Akira, did you expect these packages to fix the hanging problem with Emacs? Or are they merely "stepping stones" to more fixes?

(In reply to comment #32)
> I can still get Emacs to hang with libgxim-0.3.0-1.fc10 and
> imsettings-0.105.0-1.fc10.
> 
> Akira, did you expect these packages to fix the hanging problem with Emacs? Or
> are they merely "stepping stones" to more fixes?

still need more fix, particularly in IM side. as you can see from the debug log I've mentioned at Comment #7, these packages will workaround the race condition issue causing this freeze (for root cause, see Bug#465392 for SCIM). however that's all I can do something in imsettings. after that, it just looks like emacs freezes because IM sends back same key release events as the response what you input and emacs doesn't display anything against the key release event. see Bug#466657 for more details. I've attached the testing code to reproduce the issue temporarily.

I'll make a patch for that soon.

this issue should be gone with scim-1.4.7-35.fc10.

Ok, I'll test and report back.

Alas, I can still get emacs to hang, even with scim-1.4.7-35.fc10.

If it matters, I am using the sawfish window manager (yes, I know it's ancient), with the following custom bindings:

Meta+F1: previous workspace
Meta+F2: next workspace
Ctrl+Meta+Button1: move window interactively
Meta+Button1: raise window
Meta+Button3: lower window

Emacs only seems to hang when I use one of these bindings while the emacs window has focus.

E.g.:

1. Launch a new emacs.
2. Move the cursor outside of the emacs window.
3. Alternate between pressing Meta+F1 and Meta+F2, to switch between the workspace with the emacs window and the previous (or next) workspace.
4. While continuing to alternate between pressing Meta+F1 and Meta+F2, use the mouse to move the cursor into the emacs window, and continue to move it around within the emacs window.

Within a few seconds, emacs hangs.  :(

If it helps, I have strace output from performing the above steps...

Oh, okay. yes, if you can give me more information, that would be very helpful. and please follow up the steps at Comment #7 as well.

nevermind. confirmed with even metacity with similar steps.

should be fixed in libgxim-0.3.1-1.fc10 and imsettings-0.105.1-1.fc10.

Since I updated to libgxim-0.3.1-1.fc10 and imsettings-0.105.1-1.fc10, I haven't been able to get Emacs to hang.

sangu, are you still seeing hangs?

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

We've passed through certain time to see a fix. please reopen if you still see this issue.