Yong Sun wrote: > [4] scim::__initialize_config(), line 131 in "scim_global_config.cpp" > [5] scim::scim_global_config_read(key = CLASS, defVal = 5000), line 183 in > "scim_global_config.cpp" > [6] scim::scim_get_default_socket_timeout(), line 1214 in "scim_socket.cpp" > [7] scim::PanelClient::PanelClientImpl::PanelClientImpl(this = 0x8085318), > line 86 in "scim_panel_client.cpp" > [8] scim::PanelClient::PanelClient(this = 0xfbfe9510), line 566 in > "scim_panel_client.cpp" > [9] __SLIP.INIT_I(0xfbfe11e8, 0xfbfc33f9, 0x8046e8c, 0xfbfcd807, 0xfeffa7d0, > 0xfe660438), at 0xfbfb035f > [10] __STATIC_CONSTRUCTOR(), line 301 in "gtkimcontextscim.cpp" > [11] __cplus_fini_at_exit(0xfbf93760, 0xfe660438, 0xfeffa7d0, 0xfbc10df8, > 0xfefd05dc, 0xfbc10df8), at 0xfbfcd807 > [12] call_init(0xfbc10df8, 0x3), at 0xfefd380f > [13] is_dep_init(0xfe660438, 0xfbf80490), at 0xfefd357c > [14] elf_bndr(0xfbf80490, 0x2d8, 0xfbe6ccbf), at 0xfefde53c > [15] elf_rtbndr(0x2d8, 0xfbe6ccbf, 0xfbfe9594, 0x0, 0xfbf2f200, 0xfbe6cc79), > at 0xfefc8c24 > [16] 0xfbf80490(0xfbf2f200, 0xfbe6cda9, 0x8046fcc, 0xfbf0890b, 0xfeffa7d0, > 0xfbf80490), at 0xfbf80490 > [17] __STATIC_CONSTRUCTOR(), line 42 in "string.cc" > [18] __cplus_fini_at_exit(0xfeffa2d8, 0xfe660438, 0xfeffa7d0, 0xc, 0x8047024, > 0xfefd7d91), at 0xfbf0890b > [19] call_init(0xfbc10db0, 0x1), at 0xfefd380f > [20] load_completion(0xfe660438, 0xfec425b0), at 0xfefd3dfa > [21] dlmopen_intn(0xfeffa2d8, 0x8066c40, 0xd01, 0xfec425b0, 0x0, 0x0, > 0x80470d0), at 0xfefd7ff0 > [22] dlmopen_check(0xfeffa2d8, 0x8066c40, 0xd01, 0xfec425b0, 0x80470d0), at > 0xfefd80e0 > [23] _dlopen(0x8066c40, 0x101), at 0xfefd81a1 > [24] _g_module_open(0x8066c40, 0x1, 0x0), at 0xfc59118a > [25] g_module_open(0x8065008, 0x0), at 0xfc59175c > [26] query_module(0x8064308, 0xfee84042), at 0x805137a > [27] main(0x1, 0x80471f0, 0x80471f8), at 0x8051651
Perhaps you have a cyclic dependency. This trace shows that ld.so.1 has kicked off a .init [19] as part of the dlopen [23]. From exercising the __STATIC_CONSTRUCTOR [17], ld.so.1 has been asked to bind to another function [15], which is presumably to an object whose init hasn't fired yet. Before the binding is established, ld.so.1 calls the defining objects .init [12]. If you turned on the runtime linkers debugging, I 'd expect you'd see something like: 09086: calling .init (dynamically triggered): ./libXXXX.so.1 For a description of the complexities of init/fini processing, see: http://blogs.sun.com/rie/entry/init_and_fini_processing_who -- Rod.
