Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 134304 - [cannaLE] random gtk2 delays, auxmenu defunct
Summary: [cannaLE] random gtk2 delays, auxmenu defunct
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: im-sdk
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: IIIMF FC3Blocker
TreeView+ depends on / blocked
 
Reported: 2004-10-01 07:45 UTC by Warren Togami
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: im-sdk-12.0.1-17.svn1994
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-19 02:20:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Warren Togami 2004-10-01 07:45:56 UTC
Description of problem:
It seems that all newer snapshots of svn1943 have severe trouble with
canna.  All kinds of difficult behavior like:

* Sometimes gtk2 windows or tabs take 2 seconds to draw, spinning with
100% CPU usage.
* Sometimes gtk2 windows or tabs take 2-5 seconds to close, spinning
with 100% CPU usage.
* Sometimes applications like xchat, firefox, or gaim crash completely.
* Sometimes canna fails to activate at all.
* Sometimes canna activates, but fails to convert any input text.

considering to use lang ja
searching module... CannaLE.so
During window open, htt_server -d stuck here, then completes drawing
and outputs:
Create session context(8ba12f8)

#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6dcc444 in poll () from /lib/tls/libc.so.6
#2  0x08091bbe in IMSocketListen::accept (this=0x8b58748) at
IMUtil.cpp:632
#3  0x08072b61 in IIIMProtocol::accept (this=0x8b615d0, flags=0) at
IIIMProtocol.cpp:59
#4  0x0806e904 in IMScheduler_MTPC::start (this=0x8b50800) at
IMScheduler_MTPC.cpp:53
#5  0x0804da8a in IMSvr::start (this=0xfef0aa00) at IMSvr.cpp:82
#6  0x0804d44a in main (argc=2, argv=0xfef0ab74) at main.cpp:44
#7  0xf6d26af3 in __libc_start_main () from /lib/tls/libc.so.6
#8  0x0804d1f9 in _start ()

Above is a backtrace during this window open spinning.

Version-Release number of selected component (if applicable):
im-sdk-12.0.1-10.svn1943

Comment 1 Warren Togami 2004-10-01 07:52:34 UTC
warren   11509  7177  0 21:29 ?        00:00:00 [auxmenu] <defunct>
I forgot to mention that I have dozens of these defunct processes that
are unkillable with even kill -9.  tagoh thinks this is somehow
related to the trouble I am seeing.


Comment 2 Warren Togami 2004-10-01 08:06:00 UTC
(gdb) thread apply all bt full

Thread 2 (Thread -154874960 (LWP 11737)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0xf6e694cb in __read_nocancel () from /lib/tls/libpthread.so.0
No symbol table info available.
#2  0x00bac1a3 in RkcRecvWReply () from /usr/lib/libcanna.so.1
No symbol table info available.
#3  0x00bacc59 in RkcSendWRequest () from /usr/lib/libcanna.so.1
No symbol table info available.
#4  0x00000005 in ?? ()
No symbol table info available.
#5  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread -154156288 (LWP 11734)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0xf6dcc444 in poll () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x08091bbe in IMSocketListen::accept (this=0x9d6f748) at
IMUtil.cpp:632
        fd = 8
        i = 1
        fds = (pollfd *) 0x9d7dd10
        it = {_M_current = 0x9d6f764}
        pims = (IMSocket *) 0x9d78678
        n = 1
#3  0x08072b61 in IIIMProtocol::accept (this=0x9d785d0, flags=0) at
IIIMProtocol.cpp:59
        pimt = (IIIMPTrans *) 0xfeedb194
        pims = (class IIIMP_IMState *) 0xf6e32ff4
        pimst = (class IMSocketTrans *) 0x0
#4  0x0806e904 in IMScheduler_MTPC::start (this=0x9d67800) at
IMScheduler_MTPC.cpp:53
        pims = (class IMState *) 0x0
        th = 4140092336
        attr = {__detachstate = 0, __schedpolicy = 0, __schedparam =
{__sched_priority = 1}, __inheritsched = 4096,
  __scope = 0, __guardsize = 0, __stackaddr_set = 0, __stackaddr =
0x0, __stacksize = 0}
#5  0x0804da8a in IMSvr::start (this=0xfeedb020) at IMSvr.cpp:82
No locals.
---Type <return> to continue, or q <return> to quit---
#6  0x0804d44a in main (argc=2, argv=0xfeedb194) at main.cpp:44
        svr = {<IMAccept> = {_vptr.IMAccept = 0x8098610}, pcfg =
0xfeedb0b0, usermgr = {<IMAuth> = {
      _vptr.IMAuth = 0x8099250, ae_num = 3, alloced_ae_num = 10,
auth_type = 2, pae = 0x9d669e8, def_at = DENY, sm = {
        alloced_size = 10, size = 2, psym = 0x9d66990}, from_address =
0x0, from_address_bitlen = 0,
      from_hostname = 0x9d7a5e0 "localhost", command_name = 0x9d6fc30
"/usr/sbin/htt_server", domainname = 0x0},
    alloced_ue_num = 0, ue_num = 0, pue = 0x0, sysuser_at =
IMAuth::PASSWORD, usermap = {_M_t = {
        _M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<const
u16string, IMUser*> > >> =
{<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<const
u16string, IMUser*> > >> = {<No data fields>}, <No data fields>},
          _M_key_compare =
{<std::binary_function<u16string,u16string,bool>> = {<No data
fields>}, <No data fields>},
          _M_header = {_M_color = std::_S_red, _M_parent = 0x9d7dd50,
_M_left = 0x9d7dd50, _M_right = 0x9d7dd50},
          _M_node_count = 1}}}}, plemgr = 0x9d7a340, pimprotocol =
0x9d785d0,
  addrvec =
{<std::_Vector_base<IMSocketAddress,std::allocator<IMSocketAddress> >> = {
      _M_impl = {<std::allocator<IMSocketAddress>> =
{<__gnu_cxx::new_allocator<IMSocketAddress>> = {<No data fields>}, <No
data fields>}, _M_start = 0x9d6f730, _M_finish = 0x9d6f744,
_M_end_of_storage = 0x9d6f744}}, <No data fields>},
  imclist =
{<std::_List_base<IMConnection*,std::allocator<IMConnection*> >> = {
      _M_impl = {<std::allocator<std::_List_node<IMConnection*> >> =
{<__gnu_cxx::new_allocator<std::_List_node<IMConnection*> >> = {<No
data fields>}, <No data fields>}, _M_node = {_M_next = 0x9d7de28,
_M_prev = 0x9d7de28}}}, <No data fields>},
  pkeyparser = 0x9d7a580}
        pimlog = (class IMLog *) 0x9d677e8
        pimsch = (class IMScheduler *) 0x9d67800
        pimobjmgr = (IMObjectMgr *) 0x9d67810
        exitcode = -152883212
        arg = {<IMSvrCfg> = {_vptr.IMSvrCfg = 0x8098968, pbase = 0x0,
popts = 0x9d66034, command_name = {
      static npos = 4294967295,
      _M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
        _M_p = 0x9d66014 "/usr/sbin/htt_server"}}}, valid_flag = true,
pxmlsvrcfg = 0x9d6f8a0, pxmllecfg = 0x9d6f8f0,
  optmap = {_M_t = {
      _M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<const
char* const, IMSvrArg::ArgVal> > >> =
{<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<const char*
const, IMSvrArg::ArgVal> > >> = {<No data fields>}, <No data fields>},
        _M_key_compare = {<No data fields>}, _M_header = {_M_color =
std::_S_red, _M_parent = 0x9d666c0,
          _M_left = 0x9d667e0, _M_right = 0x9d66960}, _M_node_count =
15}}}}
        pimsignal = (IMSignal *) 0x9d66fb8
        ptls = (class IMTLS *) 0x9d67810
#7  0xf6d26af3 in __libc_start_main () from /lib/tls/libc.so.6
No symbol table info available.
#8  0x0804d1f9 in _start ()
No symbol table info available.


Comment 3 Warren Togami 2004-10-06 08:35:26 UTC
12.0.1-8.svn1891 seems to have the same problem, although seemingly
less serious.  In any case, I consider this to be serious enough to be
a FC3 blocker.

Comment 4 Akira TAGOH 2004-10-06 13:49:01 UTC
12.0.1-13.svn1943 should be better than others. at least it's no
auxmenu defunct and no crashes for me. please try.

Comment 5 Warren Togami 2004-10-09 22:22:03 UTC
auxmenu still somehow becomes defunct, although not as easily. 
Crashes are indeed gone, but slowness is still apparent.

Comment 6 Akira TAGOH 2004-10-12 05:02:38 UTC
btw doesn't this problem appear on iiimf-le-chinput which also uses
the aux object?

Comment 7 Warren Togami 2004-10-13 05:08:38 UTC
The gtk2 delays seem gone with -14, and so far no auxmenu defunct
processes yet.  Please keep this open a day or two for verification. 
I will test with cannaLE, and llim should test with S Chinese.

Comment 8 Akira TAGOH 2004-10-18 09:54:34 UTC
any progress for testing?

Comment 9 Warren Togami 2004-10-18 09:57:20 UTC
Good news: No defunct processes.
Bad  news: Slow gtk2 window closing when cannaLE is the current LE.


Comment 10 Lawrence Lim 2004-10-18 10:07:17 UTC
Nothing significant for both cannaLE and chinput LE. auxmenu does not
appear anymore. I will leave it turn on tonight and see if anything
will happen. :)

However, I did notice the gtk2 window closing issue on my box as well.


Comment 11 Lawrence Lim 2004-10-19 02:20:07 UTC
Confirmed fixed in im-sdk-12.0.1-17.svn1994. Resolving the bug for now.


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