Description of problem: It crashes but cannot be 100%. But once it crashes the trace will be something same to this. Version-Release number of selected component (if applicable): 12.1-1 How reproducible: Steps to Reproduce: 1. LANG=ta_IN.UTF-8 gedit 2. wait for htt_server to crash Actual results: crash Expected results: not crash Additional info: Thread 2 (Thread -153994320 (LWP 16904)): #0 0xf6e80a60 in fgets () from /lib/tls/libc.so.6 #1 0xf62d868d in LoadTableHeader (file_name=0xf6d20520 "\n", unit_table=0xf6d20650) at codepoint_table.c:209 #2 0xf62d82c5 in codepoint_Init (core=0x9eaaec8) at codepoint_im.c:112 #3 0xf6fdc0c5 in open_engine (udp=0x9e85150, locale_id=0, locale_name=0xf6d21af0 "UNICODE-HEX", engine_name=0xf6d21df0 "codepoint", engine_path=0xeab138 <Address 0xeab138 out of bounds>, engine_options=0x0) at unit_input.c:740 #4 0xf6fdcb06 in unit_ns_read_config (udp=0x9e85150, buf=0x9ea5690 "[ GENERIC_IM_TABLE ] \n\n[ SWITCH_LOCALE ]\nIM_VK_F5 0\n\n[ SWITCH_LAYOUT ]\nIM_VK_F6 0\n\n[ en ]\neuro common/xctim.so EUROPEAN\n\n[ he ]\nhebrew common/xctim.so HEBREW\n\n[ ar ]\narabic common/xctim.so ARABIC\n\n[ r"..., fsize=1410) at unit_input.c:528 #5 0xf6fdd021 in unit_ns_callback (listener_id=1, fsize=0, buf=0x0, calldata=0x0) at unit_input.c:395 #6 0x08068ae0 in IMInputContext::invoke_desktop_listener (this=0x0, pimlex=0x9e859b8, listener_id=1, file_size=15380792, object=0xeab138) at IMInputContext.cpp:191 #7 0x0806fbfb in IIIMP_ICState_REQUESTED::process_read_ns_reply (this=0x0, pmes=0x0) at ICState.hh:172 #8 0x08076aa0 in IIIMP_ICState_WAITING::match_waiting_message ( this=0x9ea5498, pmes=0x9e8d4d0) at IIIMP_ICState.cpp:1208 #9 0x0807896c in IIIMP_ICState_WAITING::message_proc (this=0x9ea5498, x_pmes=0x9e8d4d0) at IIIMP_ICState.cpp:1229 #10 0x0806aa8b in ICState::deliver (this=0x9e842e8, message=0xeab138) at ICState.cpp:17 #11 0x0806a3d7 in IMState::dispatch (this=0x9e8d5d0, im_id=1, ic_id=1, message=0x9e8d4d0) at stl_tree.h:175 #12 0x0806b3d4 in IIIMProtocol::receive_and_dispatch (this=0x9e89a40, pims=0x9e8d5d0, flags=0) at IIIMProtocol.cpp:32 #13 0x08069833 in IMScheduler_MTPC_thread_entry (priv=0x0) at IMScheduler_MTPC.cpp:25 #14 0xf6f821d5 in start_thread () from /lib/tls/libpthread.so.0 #15 0xf6ef319a in clone () from /lib/tls/libc.so.6 Thread 1 (Thread -152995520 (LWP 16900)): #0 0xf6fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xf6ee9564 in poll () from /lib/tls/libc.so.6 #2 0x0809206c in IMSocketListen::accept (this=0x9e80bb8) at IMUtil.cpp:651 ---Type <return> to continue, or q <return> to quit--- #3 0x0806b44c in IIIMProtocol::accept (this=0x9e89a40, flags=0) at IIIMProtocol.cpp:59 #4 0x0806988d in IMScheduler_MTPC::start (this=0x9e78c70) at IMScheduler_MTPC.cpp:53 #5 0x0804d9ca in IMSvr::start (this=0xfffffffc) at IMScheduler.hh:24 #6 0x0804d755 in main (argc=-4, argv=0xfeecb4e4) at main.cpp:44 #7 0xf6e42e33 in __libc_start_main () from /lib/tls/libc.so.6 #8 0x0804d621 in _start () #0 0xf6e80a60 in fgets () from /lib/tls/libc.so.6
I can nearly 100% reproduce it when i run with: # gdb --args htt_server -d I have lesser chance reproduce it when i run with: # htt_server -d I have not yet reproduce it when i run with: # valgrind --tool=memcheck htt_server -d Can this narrow down to a toolchain problem?
I recompiled im-sdk 12.1-1 on rawhide-20041024. After installing these rpms, and quite a bit of testing, i was not able to crash the htt server. This looks like a toolchain problem to me now. Leon, can you do the same on your end and verify?
I can still able to reproduce it after recompliation.
Actually I can able to crash htt_server running with valgrind. However it is much harder (For one time I need over 30 runs of gedit to get one crash): Here is the valgrind output of last mem error before segfault: -- if_le_CreateSC() : Loading Engines ... if_le_SetSCFocus() s:1bf98d48, current_session:1bf98d48, udp:0x1bf6d358 ==2261== ==2261== Thread 2: ==2261== Invalid read of size 4 ==2261== at 0x80769A3: ??? (IIIMP_ICState.cpp:1205) ==2261== by 0x807896B: ??? (IIIMP_ICState.cpp:1229) ==2261== by 0x806AA8A: ??? (ICState.cpp:17) ==2261== by 0x806A3D6: ??? (stl_tree.h:175) ==2261== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==2295== ==2295== Thread 2: ==2295== Syscall param execve(envp) contains uninitialised or unaddressable byte(s) ==2295== at 0x9274BF: execve (in /lib/tls/libc-2.3.3.so) ==2295== by 0x9277FA: execl (in /lib/tls/libc-2.3.3.so) ==2295== by 0x8055D3F: ??? (basic_string.h:1452) ==2295== by 0x8055DFE: ??? (IMSignal.cpp:36) ==2295== Address 0x52BFE8F0 is not stack'd, malloc'd or (recently) free'd ==2295== ==2295== Thread 2: ==2295== Syscall param execve(envp[i]) contains uninitialised or unaddressable byte(s) ==2295== at 0x9274BF: execve (in /lib/tls/libc-2.3.3.so) ==2295== by 0x9277FA: execl (in /lib/tls/libc-2.3.3.so) ==2295== by 0x8055D3F: ??? (basic_string.h:1452) ==2295== by 0x8055DFE: ??? (IMSignal.cpp:36) ==2295== Address 0x52BFEA1E is not stack'd, malloc'd or (recently) free'd /proc/2261/exe: No such file or directory. /root/2261: No such file or directory.Killed [root@reflex ~]# /usr/lib/im/share/iiim/gdbcmd:1: Error in sourced command file: No stack.
Look like some code in per-user config creates this screwing effect. Will need to backport to make fc3 stable until further improvement on that particular implementation, as it is important for Indic users for FC3.
Fixed in -4 in dist-fc3-HEAD right?
Revented to stable state. Tagoh-san has rebuilt it in 12.1-4.
still happens, another backtrace is here: (gdb) thread apply 2 bt Thread 2 (Thread -1208271952 (LWP 11181)): #0 0x0019b7a2 in ?? () at rtld.c:577 from /lib/ld-linux.so.2 #1 0x003f23fb in ?? () from /lib/tls/libpthread.so.0 #2 0x08055e38 in IMSignal::_segv (this=0x893fb78, num=11) at IMSignal.cpp:104 #3 0x08055f9f in IMSignal::segv (this=0xfffffe00) at IMSignal.cpp:36 #4 0x080552f0 in signal_handler (num=0) at IMSignal.cpp:137 #5 <signal handler called> #6 0x08077063 in IIIMP_ICState_WAITING::match_waiting_message (this=0x894db18, pmes=0x8960fe8) at IIIMP_ICState.cpp:1203 #7 0x0807903c in IIIMP_ICState_WAITING::message_proc (this=0x894db18, x_pmes=0x8960fe8) at IIIMP_ICState.cpp:1227 #8 0x0806b0eb in ICState::deliver (this=0x89502b8, message=0x894db18) at ICState.cpp:17 #9 0x0806aa47 in IMState::dispatch (this=0x8964ae0, im_id=1, ic_id=1, message=0x8960fe8) at stl_tree.h:175 #10 0x0806ba34 in IIIMProtocol::receive_and_dispatch (this=0x8950ac0, pims=0x8964ae0, flags=0) at IIIMProtocol.cpp:32 #11 0x08069ea3 in IMScheduler_MTPC_thread_entry (priv=0x0) at IMScheduler_MTPC.cpp:25 #12 0x003ec1d5 in start_thread (arg=0x0) at pthread_create.c:269 #13 0x0027d2da in ?? () from /lib/tls/libc.so.6 (gdb) thread apply 2 frame 6 Thread 2 (Thread -1208271952 (LWP 11181)): #6 0x08077063 in IIIMP_ICState_WAITING::match_waiting_message (this=0x894db18, pmes=0x8960fe8) at IIIMP_ICState.cpp:1203 1203 u16string mimname = CONV_IIIMP_STR(pmes->v.aux_simple.input_method_name); Current language: auto; currently c++ (gdb) p pmes $1 = (IIIMP_message *) 0x8960fe8 (gdb) p pmes->v $2 = {connect = {byte_order = 1, protocol_version = 0, user_name = 0x894db70, auth = 0x0}, connect_reply = { language = 0x1}, disconnect = {dummy = "\001"}, disconnect_reply = {dummy = "\001"}, register_trigger_keys = { trigger_on = 0x1, trigger_off = 0x0}, trigger_notify = {flag = 1}, trigger_notify_reply = {dummy = "\001"}, register_hotkeys = {scope_and_profile_id = 1, scope = 0, profile_id = 143973232, hotkeys = 0x0}, select_hotkey_profile = { scope_and_profile_id = 1, scope = 0, profile_id = 143973232}, hotkey_notify = {hotkey_id = 1, index = 0}, hotkey_notify_reply = {dummy = "\001"}, hotkey_state_notify = {hotkey_id = 1, current_state_flag = 0}, hotkey_state_notify_reply = {dummy = "\001"}, im_read_ns = {listener_id = 1, filename = 0x0}, im_read_ns_reply = { listener_id = 1, size = 0, object = 0x894db70}, setimvalues = {attr_list = 0x1}, setimvalues_reply = {dummy = "\001"}, getimvalues = {attr_list = 0x1}, getimvalues_reply = {attr_list = 0x1}, forward_event = {contents = 0x1}, forward_event_reply = {dummy = "\001"}, commit_string = {contents = 0x1}, forward_event_with_operations = { contents = 0x1, operation = 0x0}, forward_event_with_operations_reply = {operation = 0x1}, createic = { attr_list = 0x1}, createic_reply = {dummy = "\001"}, destroyic = {dummy = "\001"}, destroyic_reply = {dummy = "\001"}, seticvalues = {attr_list = 0x1}, seticvalues_reply = {dummy = "\001"}, geticvalues = {attr_list = 0x1}, geticvalues_reply = {attr_list = 0x1}, seticfocus = {dummy = "\001"}, seticfocus_reply = {dummy = "\001"}, unseticfocus = {dummy = "\001"}, unseticfocus_reply = {dummy = "\001"}, resetic = {dummy = "\001"}, resetic_reply = { dummy = "\001"}, preedit_start = {dummy = "\001"}, preedit_start_reply = {maximum_length = 1}, preedit_draw = { caret = 1, change_first = 0, change_length = 143973232, preedit = 0x0}, preedit_draw_reply = {dummy = "\001"}, preedit_done = {dummy = "\001"}, preedit_done_reply = {dummy = "\001"}, status_start = {dummy = "\001"}, status_start_reply = {dummy = "\001"}, status_draw = {status = 0x1}, status_draw_reply = {dummy = "\001"}, status_done = { dummy = "\001"}, status_done_reply = {dummy = "\001"}, lookup_choice_start = {master = 1, choice_per_window = 0, rows = 143973232, columns = 0, direction = 1, label_owner = 143978228}, lookup_choice_start_reply = {dummy = "\001"}, lookup_choice_draw = {first = 1, last = 0, current = 143973232, choice = 0x0, index_label = 0x1, title = 0x894eef4}, lookup_choice_draw_reply = {dummy = "\001"}, lookup_choice_done = {dummy = "\001"}, lookup_choice_done_reply = { dummy = "\001"}, lookup_choice_process = {type = 1, value = 0}, lookup_choice_process_reply = {dummy = "\001"}, aux_simple = {class_index = 1, input_method_name = 0x0}, aux_value = {class_index = 1, input_method_name = 0x0, integer_value = 0x894db70, string_value = 0x0}, aux_start = {class_index = 1, input_method_name = 0x0}, aux_start_reply = {class_index = 1, input_method_name = 0x0}, aux_draw = {class_index = 1, input_method_name = 0x0, integer_value = 0x894db70, string_value = 0x0}, aux_draw_reply = {class_index = 1, input_method_name = 0x0}, aux_done = {class_index = 1, input_method_name = 0x0}, aux_done_reply = {class_index = 1, input_method_name = 0x0}, aux_setvalues = {class_index = 1, input_method_name = 0x0, integer_value = 0x894db70, string_value = 0x0}, aux_setvalues_reply = {class_index = 1, input_method_name = 0x0}, aux_getvalues = {class_index = 1, input_method_name = 0x0, integer_value = 0x894db70, string_value = 0x0}, aux_getvalues_reply = {class_index = 1, input_method_name = 0x0, integer_value = 0x894db70, string_value = 0x0}, protocol_version = {number = 1}} (gdb) p pmes->v.aux_simple $3 = {class_index = 1, input_method_name = 0x0} (gdb) p pmes->v.aux_simple.input_method_name $4 = (IIIMP_string *) 0x0
Well, in IIIMPUtil.hh, #define CONV_IIIMP_STR(ps) (((ps)->len > 0) ? u16string((ps)->ptr, (ps)->len) : u16string("")) This macro assumes that ps isn't NULL. but as gdb says, it was NULL. I'm not 100% sure if this code also assumes input_method_name doesn't have to be NULL or this macro should do NULL-check.
*** Bug 136753 has been marked as a duplicate of this bug. ***
should be fixed in 12.1-7
Confirmed fixed in im-sdk-12.1-7. I can activate UnitLE through the hotkey menu and from the GIMLET (except bn).