This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 156672 - (xchat) iiimd 100% CPU
(xchat) iiimd 100% CPU
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xchat (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: i18n
Depends On:
Blocks: FC4Update
  Show dependency treegraph
 
Reported: 2005-05-03 02:02 EDT by Warren Togami
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 03:59:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
proposed patch (683 bytes, patch)
2005-06-10 03:52 EDT, Akira TAGOH
no flags Details | Diff

  None (edit)
Description Warren Togami 2005-05-03 02:02:35 EDT
iiimf-server-12.2-0.7.svn2578
LANG=en_US.UTF-8

[root@fedora64 tmp]# strace -p 2529
Process 2529 attached - interrupt to quit
poll(

strace is unable to see anything happen, it just gets stuck here while 100% CPU
continues to be used.  gdb attach and bt sees this.

(gdb) bt
#0  0x00000030d04c059d in poll () from /lib64/libc.so.6
#1  0x000000000044262a in IMSocketListen::accept (this=Variable "this" is not
available.
) at IMUtil.cpp:871
#2  0x0000000000421b81 in IIIMProtocol::accept (this=0x7a3690, flags=Variable
"flags" is not available.
) at IIIMProtocol.cpp:59
#3  0x0000000000433a54 in IMSvr::start (this=0x7ffffff5d950) at IMSvr.cpp:80
#4  0x0000000000450ce2 in main (argc=Variable "argc" is not available.
) at main.cpp:44
#5  0x00000030d041c49c in __libc_start_main () from /lib64/libc.so.6
#6  0x0000000000408db9 in _start ()
#7  0x00007ffffff5db88 in ?? ()
#8  0x0000000000000000 in ?? ()

I can't reproduce this easily.
Comment 1 Akira TAGOH 2005-05-05 23:59:42 EDT
Yep, I saw the same problem, but not sure how to reproduce it easily as well. 
When I saw this, iiimd is in the infinite loop with -EPIPE.
Comment 2 Warren Togami 2005-05-27 03:00:31 EDT
xchat-2.4.3-3
iiimf-server-12.2-4

I'm able to reliably trigger one case of this now.  LANG=en_US.UTF-8 xchat

1. type one line of english text, CTRL-SPACE, ENTER
2. type one line of english text, CTRL-SPACE, ENTER

xchat is stuck, using 75% CPU.  iiimd is also stuck in a loop, using 17% CPU.

xchat strace loops this forever:
poll([{fd=3, events=POLLIN, revents=POLLIN}, {fd=15, events=POLLIN|POLLPRI},
{fd=7, events=POLLIN|POLLPRI}], 3, 0) = 1
sendto(8, "\f\0\0\7\1\0\1\0\2\0\0\0\20\0\0\0\n\0\0\0\0\0\0\0\0\0\0"..., 32,
MSG_NOSIGNAL, NULL, 0) = 32
poll([{fd=8, events=POLLIN, revents=POLLIN}], 1, 10000) = 1
recvfrom(8, "\f\0\0\7\1\0\1\0", 8, MSG_NOSIGNAL, NULL, NULL) = 8
poll([{fd=8, events=POLLIN, revents=POLLIN}], 1, 10000) = 1
recvfrom(8, "\2\0\0\0\20\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\244Xu\25", 24,
MSG_NOSIGNAL, NULL, NULL) = 24
sendto(8, "\r\0\0\1\1\0\1\0", 8, MSG_NOSIGNAL, NULL, 0) = 8
poll([{fd=8, events=POLLIN, revents=POLLIN}], 1, 10000) = 1
recvfrom(8, "\r\0\0\1\1\0\1\0", 8, MSG_NOSIGNAL, NULL, NULL) = 8
poll([{fd=3, events=POLLIN, revents=POLLIN}, {fd=15, events=POLLIN|POLLPRI},
{fd=7, events=POLLIN|POLLPRI}], 3, 0) = 1

iimd strace is stuck here until iiimd is killed:
poll([{fd=3, events=POLLIN}], 1, -1)    = -1 EINTR (Interrupted system call)
--- SIGTERM (Terminated) @ 0 (0) ---

gdb break when xchat is stuck in this loop:
(gdb) bt
#0  0x00000039e41f14f2 in _gtk_key_hash_lookup (key_hash=0x942ee0,
hardware_keycode=Variable "hardware_keycode" is not available.
) at gtkkeyhash.c:355
#1  0x00000039e4160d6b in IA__gtk_bindings_activate_event (object=0x6e6390,
event=0x6cd830) at gtkbindings.c:1133
#2  0x00000039e420375e in _gtk_marshal_BOOLEAN__BOXED (closure=0x6d50c0,
return_value=0x7fffffdf4a40, n_param_values=Variable "n_param_values" is not
available.
) at gtkmarshalers.c:83
#3  0x00000039e1c0a27d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#4  0x00000039e1c17716 in g_signal_stop_emission () from
/usr/lib64/libgobject-2.0.so.0
#5  0x00000039e1c18544 in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#6  0x00000039e1c18bb7 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#7  0x00000039e42c7a08 in gtk_widget_event_internal (widget=0x6e6390,
event=0x6cd830) at gtkwidget.c:3631
#8  0x00000039e42d41e1 in IA__gtk_window_propagate_key_event (window=0x6df7b0,
event=0x6cd830) at gtkwindow.c:4429
#9  0x00000039e42d4223 in gtk_window_key_release_event (widget=0x6df7b0,
event=0x6cd830) at gtkwindow.c:4477
#10 0x00000039e420375e in _gtk_marshal_BOOLEAN__BOXED (closure=0x6d50c0,
return_value=0x7fffffdf5060, n_param_values=Variable "n_param_values" is not
available.
) at gtkmarshalers.c:83
#11 0x00000039e1c0a27d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#12 0x00000039e1c17716 in g_signal_stop_emission () from
/usr/lib64/libgobject-2.0.so.0
#13 0x00000039e1c18544 in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#14 0x00000039e1c18bb7 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#15 0x00000039e42c7a08 in gtk_widget_event_internal (widget=0x6df7b0,
event=0x6cd830) at gtkwidget.c:3631
#16 0x00000039e42021c1 in IA__gtk_propagate_event (widget=0x679c40,
event=0x6cd830) at gtkmain.c:2119
#17 0x00000039e42024f4 in IA__gtk_main_do_event (event=0x6cd830) at gtkmain.c:1383
#18 0x00000039e4540051 in gdk_event_dispatch (source=Variable "source" is not
available.
) at gdkevents-x11.c:2221
#19 0x00000039e162499e in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#20 0x00000039e1627644 in g_main_context_check () from /usr/lib64/libglib-2.0.so.0
#21 0x00000039e1627b30 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#22 0x00000039e4201a75 in IA__gtk_main () at gtkmain.c:963
#23 0x000000000041400c in fe_main () at fe-gtk.c:297
#24 0x0000000000449f45 in main (argc=Variable "argc" is not available.
) at xchat.c:1127
#25 0x00000039dec1c4cc in ?? ()
#26 0x000000000000001f in ?? ()
#27 0x00007fffffdf6708 in ?? ()
#28 0x00000001ffdf6708 in ?? ()
#29 0x00000000004493ed in new_ircwindow (serv=Variable "serv" is not available.
) at xchat.c:404
#30 0x0000000000000005 in ?? ()
#31 0x0000000000000009 in ?? ()
#32 0x0000000000000007 in ?? ()
#33 0x0000000000000000 in ?? ()

I am unable to gdb break into iiim when it is stuck in this state, probably
because it is stuck in a syscall.

I forgot to mention that this is x86_64 FC4.  kernel-2.6.11-1.1340_FC4
Comment 3 Warren Togami 2005-06-05 01:14:48 EDT
This makes IIIMF pretty much unusable for me. =(
Comment 4 Jens Petersen 2005-06-08 04:33:55 EDT
xchat hard loop only seems to happen with iiim gtk immodule.
For xim input the loop can be broken with Ctrl-Space.
Comment 5 Akira TAGOH 2005-06-10 03:42:57 EDT
Apparently xchat-2.4.3-im_context_filter_keypress.patch seems not to be the
right solution anymore. I'll reassigning this to xchat and attach a patch to
solve this problem.
Comment 6 Akira TAGOH 2005-06-10 03:52:48 EDT
Created attachment 115287 [details]
proposed patch

it wasn't the right solution anymore since gtk_im_context_filter_keypress is
called in GtkEntry's default keyevent handler. but still need to pass the key
event to IM first. so key_handle_key_press() needs to be connected after that
anyway.
Comment 7 Peter Zelezny 2005-06-13 23:49:21 EDT
May be related to:

http://sourceforge.net/tracker/?func=detail&atid=100239&group_id=239&aid=896968
Comment 8 Martin Ellison 2005-07-03 04:38:58 EDT
It's happening for me too -- for me iiimd is blowing out to >1GB and then the
system thrashes (I have 'only' 512MB).
Comment 9 Akira TAGOH 2005-07-04 04:04:30 EDT
which version of iiimf are you using? and what application are you mainly using?
Comment 10 Martin Ellison 2005-07-04 07:53:25 EDT
I as using whatever came with Fedora Core 4. I was running gaim but the problem
still occurs without it. [I'm updating using yum at the moment so I can't tell
you which version it was].
Comment 11 Warren Togami 2005-07-06 01:27:45 EDT
At some point we need to issue an FC4 update of xchat to prevent this issue. 
There seem to be other apps in FC4 that cause this behavior though. =(
Comment 12 Akira TAGOH 2005-07-06 01:42:20 EDT
Comment #10:
Thanks for the info. BTW which arch are you running on? I suppose it's amd64 or so.
Comment 13 Leon Ho 2006-07-11 03:59:37 EDT
Since we've moved to SCIM. Put this as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.