Bug 206995 - launching scim xim segfaults when already running
launching scim xim segfaults when already running
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: scim (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peng Huang
: MoveUpstream
Depends On:
Blocks: 210449
  Show dependency treegraph
 
Reported: 2006-09-18 13:15 EDT by Scott Tsai
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
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:


Attachments (Terms of Use)
uninline all exception classes. (3.59 KB, patch)
2006-11-15 21:44 EST, Peng Huang
no flags Details | Diff
uninline all exception classes. (3.59 KB, patch)
2006-11-15 21:48 EST, Peng Huang
no flags Details | Diff
uninline all exception classes. (3.59 KB, patch)
2006-11-15 21:50 EST, Peng Huang
no flags Details | Diff
uninline all exception classes. (3.59 KB, patch)
2006-11-15 21:55 EST, Peng Huang
no flags Details | Diff
skip m_module.unload() in src/scim_frontend_module.cpp. (589 bytes, patch)
2006-11-17 00:44 EST, Peng Huang
no flags Details | Diff
patch for adding patch scim-fix-unload-segfault.patch to scim.spec. (1.26 KB, patch)
2006-11-17 00:49 EST, Peng Huang
no flags Details | Diff

  None (edit)
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

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