Bug 206995

Summary: launching scim xim segfaults when already running
Product: [Fedora] Fedora Reporter: Scott Tsai <scottt.tw>
Component: scimAssignee: Peng Huang <phuang>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eng-i18n-bugs
Target Milestone: ---Keywords: MoveUpstream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-10 21:21:55 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 210449    
Attachments:
Description Flags
uninline all exception classes.
none
uninline all exception classes.
none
uninline all exception classes.
none
uninline all exception classes.
none
skip m_module.unload() in src/scim_frontend_module.cpp.
none
patch for adding patch scim-fix-unload-segfault.patch to scim.spec. none

Description Scott Tsai 2006-09-18 13:15:57 EDT
Description of problem:
running scim on the cmdline will cause it to exit abnormally.

Version-Release number of selected component (if applicable):
scim-1.4.4-9.8.fc5
scim-libs-1.4.4-9.8.fc5

How reproducible:
always

Steps to Reproduce:
1.run "scim" from the command line

Actual results:
Smart Common Input Method 1.4.4

Launching a SCIM process with x11...
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
SCIM has exited abnormally.

Expected results:
Without the "exited abnormally" part.

Additional info:
partial gdb backtrace:
<...snip...>
Core was generated by `/usr/lib64/scim-1.0/scim-launcher -c socket -e socket -f
x11'.
<...snip...>
Thread 1 (process 5632):
#0  0x00002aaaae20d110 in ?? ()
#1  0x00000039ad8d171c in __gxx_exception_cleanup (code=5390752, exc=0x524180)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:50
#2  0x00000039adb6f33d in scim::FrontEndModule::load (this=0x50aba0,
name=@0x7fff5c914a60, backend=@0x7fff5c914cb0,
    config=@0x504cb8, argc=3, argv=Variable "argv" is not available.
) at scim_frontend_module.cpp:71
#3  0x00000039adb6f490 in FrontEndModule (this=0x50aba0, name=@0x7fff5c914c90,
backend=@0x7fff5c914cb0, config=@0x504cb8,
    argc=3, argv=0x7fff5c914b10) at scim_frontend_module.cpp:46
#4  0x0000000000402f1c in main (argc=7, argv=0x7fff5c914f48) at
scim_launcher.cpp:204
#5  0x00000039ab11c784 in __libc_start_main () from /lib64/libc.so.6
#6  0x0000000000401f49 in _start ()
#7  0x00007fff5c914f38 in ?? ()
#8  0x0000000000000000 in ?? ()

I conclude that loading "/usr/lib64/scim-1.0/1.4.0/FrontEnd/x11.so" somehow
raises an c++ exception, likely a segfault.
Comment 1 Jens Petersen 2006-09-18 22:01:33 EDT
Is scim already running when you do this?
Comment 2 Scott Tsai 2006-09-19 00:32:47 EDT
Yes, the usual scripts under /etc/X11/xinit.d/ started scim already.
Comment 3 Jens Petersen 2006-09-19 00:42:47 EDT
Ok, I think that is basically the correct intended behaviour.
Scim sees that another session (scim XIM client) is already running and quits.
I guess the message should be made more friendly though.
Comment 4 Peng Huang 2006-11-14 21:50:29 EST
The reason of this BUG is that FrontEndModule will throw a exception when some
opts are failed, and scim framework will catch the exception and unload the
module. When process go out the catch block, it will clean up the exception
class. But the class is inline. Its destroy function was unloaded. then it will
gen a segment fault.
Comment 5 Scott Tsai 2006-11-14 22:34:39 EST
So the shared library got unloaded while there are still references to C++
destructor code contained inside, how exciting.
Comment 6 Peng Huang 2006-11-15 21:44:06 EST
Created attachment 141331 [details]
uninline all exception classes.

    I un-inlined all exception classes (in attached patch). It can fix this
bug. But the program still segaults on another place when system exit. The
reason is when program exit, libc or stdc++ will cleanup all global object, and
x11 frontend module register some slots to a config object (it is a global
object), and the config object will destroy when system exit. It will destroy
all slots that belong to it. slots are template class. I think they are also
inline , their text is also in the module. Destroying them has the same problem
like the exception object. :(
    It's difficult to make x11 module perfectly cleanup before unload. It seem
that scim leaks disconnect interfaces for unregister slots. So currently the
easiest way to fix the bug is that scim does not unload modules. :(
Comment 7 Peng Huang 2006-11-15 21:48:35 EST
Created attachment 141332 [details]
uninline all exception classes.

    I un-inlined all exception classes (in attached patch). It can fix this
bug. But the program still segaults on another place when system exit. The
reason is when program exit, libc or stdc++ will cleanup all global object, and
x11 frontend module register some slots to a config object (it is a global
object), and the config object will destroy when system exit. It will destroy
all slots that belong to it. slots are template class. I think they are also
inline , their text is also in the module. Destroying them has the same problem
like the exception object. :(
    It's difficult to make x11 module perfectly cleanup before unload. It seem
that scim leaks disconnect interfaces for unregister slots. So currently the
easiest way to fix the bug is that scim does not unload modules. :(
Comment 8 Peng Huang 2006-11-15 21:50:50 EST
Created attachment 141333 [details]
uninline all exception classes.

    I un-inlined all exception classes (in attached patch). It can fix this
bug. But the program still segaults on another place when system exit. The
reason is when program exit, libc or stdc++ will cleanup all global object, and
x11 frontend module register some slots to a config object (it is a global
object), and the config object will destroy when system exit. It will destroy
all slots that belong to it. slots are template class. I think they are also
inline , their text is also in the module. Destroying them has the same problem
like the exception object. :(
    It's difficult to make x11 module perfectly cleanup before unload. It seem
that scim leaks disconnect interfaces for unregister slots. So currently the
easiest way to fix the bug is that scim does not unload modules. :(
Comment 9 Peng Huang 2006-11-15 21:55:54 EST
Created attachment 141334 [details]
uninline all exception classes.

    I un-inlined all exception classes (in attached patch). It can fix this
bug. But the program still segaults on another place when system exit. The
reason is when program exit, libc or stdc++ will cleanup all global object, and
x11 frontend module register some slots to a config object (it is a global
object), and the config object will destroy when system exit. It will destroy
all slots that belong to it. slots are template class. I think they are also
inline , their text is also in the module. Destroying them has the same problem
like the exception object. :(
    It's difficult to make x11 module perfectly cleanup before unload. It seem
that scim leaks disconnect interfaces for unregister slots. So currently the
easiest way to fix the bug is that scim does not unload modules. :(
Comment 10 Peng Huang 2006-11-17 00:44:46 EST
Created attachment 141448 [details]
skip m_module.unload() in src/scim_frontend_module.cpp.

Scim does not unload module cleanly, so skip m_module.unload() in
src/scim_frontend_module.cpp.
Comment 11 Peng Huang 2006-11-17 00:49:27 EST
Created attachment 141449 [details]
patch for adding patch scim-fix-unload-segfault.patch to scim.spec.
Comment 12 Ramakrishna Reddy Yekulla 2007-01-18 04:35:20 EST
Version Tested against ::

scim-1.4.5-7.fc7

Steps to reproduce ::
1. Log In to gnome
2. Activate scim
3. gnome-terminal
4. from the shell 'scim'

Actual results ::
[rreddy@getafix ~]$ scim
Smart Common Input Method 1.4.5

Launching a SCIM process with x11...
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
Failed to load x11 FrontEnd module.
SCIM has exited abnormally.

Expected Result ::
Must not excite abnormally

Comment 13 Peng Huang 2007-01-18 23:59:11 EST
I think SCIM should exit, when SCIM have been ran. The original bug is the scim
will exit with segment fault. We have fixed the segment fault in scim-1.4.5-7.fc7.
Could you explain mean of the 'Must not exit abnormally'?
Thanks
Shawn