Bug 452849

Summary: [xim] successively speedy Input -> freeze
Product: [Fedora] Fedora Reporter: sangu <sangu.fedora>
Component: imsettingsAssignee: Akira TAGOH <tagoh>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: i18n-bugs, mtasaka, petersen, ralston
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-10 06:37:57 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 466657    
Bug Blocks: 438944    
Attachments:
Description Flags
input log on emacs and xterm.
none
libgxim debug log none

Description sangu 2008-06-25 09:09:04 EDT
Description of problem:
test with emacs, xterm
--------------------------
$ killall imsettings-xim
-------------------------
Test1 (without option)
$ imsettings-xim 
Launch emacs, xterm
successively speedy input on emacs, xterm.
emacs freezes
xterm works well.

--------------------------------------
Test2 (with --verbose option)
$ imsettings-xim --verbose
12582914: Adding connection for 85983278 [server comm:12582915]
12582914: FWD: SelectionRequest: 85983278(85983278)->12582913(12582915)[->39845889]
12582915: FWD: SelectionNotify: 39845889->12582915(12582915)[->85983278]
12582915: EOL'd an instance
12582916: Adding connection for 85983278 [server comm:12582917]
12582916: FWD: SelectionRequest: 85983278(85983278)->12582913(12582917)[->39845889]
12582917: FWD: SelectionNotify: 39845889->12582917(12582917)[->85983278]
12582917: EOL'd an instance
12582918: Adding connection for 85983279 [server comm:12582919]
12582919: ->: XIM_CONNECT [sent? true via only-CM (major: 0, minor: 0)]
12582918: <-: XIM_CONNECT_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_OPEN [sent? true via only-CM (major: 0, minor: 0)]
12582918: <-: XIM_OPEN_REPLY [sent? true via Property-with-CM (major: 0, minor: 0)]
12582919: ->: XIM_QUERY_EXTENSION [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_QUERY_EXTENSION_REPLY [sent? true via Property-with-CM (major:
0, minor: 0)]
12582919: ->: XIM_ENCODING_NEGOTIATION [sent? true via Property-with-CM (major:
0, minor: 0)]
12582918: <-: XIM_ENCODING_NEGOTIATION_REPLY [sent? true via only-CM (major: 0,
minor: 0)]
12582919: ->: XIM_GET_IM_VALUES [sent? true via only-CM (major: 0, minor: 0)]
12582918: <-: XIM_GET_IM_VALUES_REPLY [sent? true via Property-with-CM (major:
0, minor: 0)]
12582919: ->: XIM_CREATE_IC [sent? true via Property-with-CM (major: 0, minor: 0)]
12582918: <-: XIM_CREATE_IC_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582918: <-: XIM_SET_EVENT_MASK [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_SET_IC_FOCUS [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_SET_IC_VALUES [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_SET_IC_VALUES_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_SET_IC_FOCUS [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582919: ->: XIM_SYNC_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_SET_IC_VALUES [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_SET_IC_VALUES_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582919: ->: XIM_SYNC_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_SET_IC_VALUES [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_SET_IC_VALUES_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582919: ->: XIM_SYNC_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_SET_IC_VALUES [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_SET_IC_VALUES_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582919: ->: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582919: ->: XIM_SYNC_REPLY [sent? true via only-CM (major: 0, minor: 0)]
12582919: ->: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582919: ->: XIM_SET_IC_VALUES [sent? true via Property-with-CM (major: 0,
minor: 0)]
12582918: <-: XIM_FORWARD_EVENT [sent? true via Property-with-CM (major: 0,
minor: 0)]

Successively speedy on emacs, xterm
Both emacs and xterm freeze.

Version-Release number of selected component (if applicable):
0.101.2-2.fc10.i386

How reproducible:
always

Steps to Reproduce:
1. Successively speedy input on xterm and emacs
2.
3.
  
Actual results:


Expected results:


Additional info:
scim-bridge-gtk-0.4.15-6.fc10.i386
scim-lang-korean-1.4.7-25.fc10.i386
scim-anthy-1.2.4-4.fc9.i386
scim-1.4.7-25.fc10.i386
scim-hangul-0.3.2-4.fc9.i386
scim-gtk-1.4.7-25.fc10.i386
scim-libs-1.4.7-25.fc10.i386
scim-bridge-0.4.15-6.fc10.i386

xterm backtrace in imsettings-xim --verbose
(gdb) bt
#0  0x00132416 in __kernel_vsyscall ()
#1  0x00517cbd in ___newselect_nocancel () from /lib/libc.so.6
#2  0x0060b295 in _xcb_conn_wait (c=0x9214948, cond=0x92149a8, vector=0x0, 
    count=0x0) at xcb_conn.c:340
#3  0x0060c93f in xcb_wait_for_event (c=0x9214948) at xcb_in.c:391
#4  0x002508c1 in wait_or_poll_for_event (dpy=0x9214358, wait=-1076661028)
    at xcb_io.c:100
#5  0x00250c30 in process_responses (dpy=0x9214358, wait_for_first_event=1, 
    current_error=0x0, current_request=0) at xcb_io.c:115
#6  0x002513c7 in _XReadEvents (dpy=0x9214358) at xcb_io.c:212
#7  0x0022f2cb in XIfEvent (dpy=0x9214358, event=0xbfd37774, 
    predicate=0x27d970 <_CheckCMEvent>, arg=0x9283f00 ",�0") at IfEvent.c:70
#8  0x0027e37a in _XimXRead (im=0x9283f00, recv_buf=0xbfd37910 "", 
    buf_len=2048, ret_len=0xbfd37848) at imTrX.c:448
#9  0x0027d474 in _XimReadData (im=0x9283f00, len=0xbfd3788a, 
    buf=0xbfd37910 "", buf_size=2048) at imTransR.c:154
#10 0x0027d837 in _XimRead (im=0x9283f00, len=0xbfd38a1a, buf=0xbfd37910 "", 
    buf_size=2048, predicate=0x269080 <_XimSetICValuesCheck>, arg=0x928ac08 "")
    at imTransR.c:231
#11 0x0026abac in _XimProtoSetICValues (xic=0x928ac08, arg=0x0)
    at imDefIc.c:759
#12 0x00257032 in XSetICValues (ic=0x928ac08) at ICWrap.c:339
#13 0x0805d655 in VTparse (xw=0x922cf50) at ./charproc.c:3342
---Type <return> to continue, or q <return> to quit---
#14 0x0805dbca in VTRun () at ./charproc.c:4849
#15 0x08068c06 in main (argc=8, argv=0x131280) at ./main.c:2397
Comment 1 Akira TAGOH 2008-06-25 09:25:05 EDT
That's not obviously easier to be reproduced. which IM did you use?
Comment 2 sangu 2008-06-25 09:36:01 EDT
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
Comment 3 Akira TAGOH 2008-06-25 09:48:13 EDT
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.
Comment 4 sangu 2008-06-25 10:53:27 EDT
I use scim-hangul. 
Inputting only ascii character, this issue happens.
Comment 5 Akira TAGOH 2008-06-25 23:57:00 EDT
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.
Comment 6 sangu 2008-08-30 09:47:04 EDT
The issue happens again in imsettings-0.103.0-1.fc10.
Comment 7 Akira TAGOH 2008-08-31 21:05:43 EDT
With scim-hangul? sure. can you give me a debug log following up http://code.google.com/p/libgxim/wiki/HowToDebug ?
Comment 8 Tony Fu 2008-09-09 23:16:15 EDT
requested by Jens Petersen (#27995)
Comment 9 sangu 2008-09-10 11:43:17 EDT
(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 ?
Comment 10 sangu 2008-09-10 11:48:38 EDT
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.
Comment 11 Akira TAGOH 2008-09-10 21:43:38 EDT
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?
Comment 12 sangu 2008-09-10 22:07:07 EDT
(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.
Comment 13 Akira TAGOH 2008-09-10 22:40:50 EDT
(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 "*".
Comment 14 Akira TAGOH 2008-09-14 23:45:33 EDT
Please test the package at http://tagoh.fedorapeople.org/tests/457901/. that should fixes the issue what I got from your log at least.
Comment 15 Jens Petersen 2008-09-16 05:05:29 EDT
XIM seems to be work better now with the test packages.

Sangu, could you please have a test?
Comment 16 sangu 2008-09-16 22:38:47 EDT
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
Comment 17 Akira TAGOH 2008-09-17 05:00:04 EDT
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?
Comment 18 sangu 2008-09-18 08:52:29 EDT
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
Comment 19 Akira TAGOH 2008-09-25 22:03:39 EDT
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.
Comment 20 Jens Petersen 2008-09-26 00:01:57 EDT
BTW, Sangu, have you considered using one of emacs builtin input methods for Hangul?
Does scim-hangul have big advantages over those?
Comment 21 sangu 2008-09-26 00:35:33 EDT
(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
Comment 22 Akira TAGOH 2008-09-26 05:05:35 EDT
(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.
Comment 23 James Ralston 2008-09-30 13:46:56 EDT
*** Bug 464439 has been marked as a duplicate of this bug. ***
Comment 24 James Ralston 2008-09-30 13:53:24 EDT
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...)
Comment 25 Akira TAGOH 2008-09-30 22:31:59 EDT
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.
Comment 26 Akira TAGOH 2008-10-06 08:52:38 EDT
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.
Comment 27 Akira TAGOH 2008-10-12 06:49:59 EDT
For the drop-the-key issue or the always-same-result-appears issue with faster input, I've filed Bug#466657 to SCIM. FYI.
Comment 28 Akira TAGOH 2008-10-12 06:50:49 EDT
still waiting for feedbacks of testing packages :)
Comment 29 James Ralston 2008-10-12 13:46:11 EDT
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.
Comment 30 Akira TAGOH 2008-10-13 21:16:45 EDT
(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.
Comment 31 Akira TAGOH 2008-10-14 00:53:17 EDT
Built libgxim-0.3.0-1.fc10 and imsettings-0.105.0-1.fc10.
Comment 32 James Ralston 2008-10-14 13:37:41 EDT
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?
Comment 33 Akira TAGOH 2008-10-14 21:53:26 EDT
(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.
Comment 34 Akira TAGOH 2008-10-19 06:30:43 EDT
this issue should be gone with scim-1.4.7-35.fc10.
Comment 35 James Ralston 2008-10-20 14:02:50 EDT
Ok, I'll test and report back.
Comment 36 James Ralston 2008-10-22 19:53:18 EDT
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...
Comment 37 Akira TAGOH 2008-10-22 22:59:24 EDT
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.
Comment 38 Akira TAGOH 2008-10-22 23:18:09 EDT
nevermind. confirmed with even metacity with similar steps.
Comment 39 Akira TAGOH 2008-10-23 09:31:38 EDT
should be fixed in libgxim-0.3.1-1.fc10 and imsettings-0.105.1-1.fc10.
Comment 40 James Ralston 2008-11-11 18:46:41 EST
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?
Comment 41 Bug Zapper 2008-11-25 21:28:09 EST
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
Comment 42 Akira TAGOH 2009-03-10 06:37:57 EDT
We've passed through certain time to see a fix. please reopen if you still see this issue.