Red Hat Bugzilla – Bug 62304
(Japanese i18n) kterm segmentation fault
Last modified: 2007-04-18 12:41:25 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314 Description of problem: kterm is the Japanese text console. kterm crashes with segmentation fault everytime if you hit SHIFT-SPACE twice in a row (as if you wanted to use kinput2 XIM). This kterm is independent of kinput2 because it occurs even without kinput2 running. kterm does NOT crash if "LANG=en_US". It only seems to crash when "LANG=ja_JP". HOWTO reproduce: Set Skipjack to "ja_JP" LANG in /etc/sysconfig/i18n. Canna server running in background. Set KDE to Japanese mode. Run Konsole and run the following: kinput2 -canna & (this is optional) kterm Within kterm, hit SHIFT-SPACE twice in a row. kterm crashes and konsole shows an error message in kana. SEGUMENTESHON <can't read these kanji> DESU. I'm sure this means segmentation fault. Here's the strange part... if you run kterm like this: LANG=en_US kterm Then SHIFT-SPACE will not crash (nothing will happen - expected behavior), and if kinput2 is running in the background then it works properly, allowing working Japanese input like in this screenshot. http://www.mplug.org/archive/2002/kinput2_kterm_working.png This is strange because kterm ALWAYS crashes when it is running in its native language, but with LANG set to en_US it works perfectly. kterm in Red Hat 7.2 worked in both cases. I am quite sure this is not a kinput2 problem. Version-Release number of selected component (if applicable): Skipjack beta-1 with up2date (3-27-2002) How reproducible: Always
Re-tested in Skipjack beta 2 Run "LANG=ja_JP kterm" and it crashes when you SHIFT-SPACE. Run "LANG=ja_JP.eucJP kterm" and it works properly.
I can't reproduce this.
Re-tested again. Now when I run "LANG=ja_JP kterm", it crashes when I hit SHIFT-SPACE five times.
Hmmm, I can't reproduce this with kinput2, skkinput, or no XIM client, no matter how many time I press shift-space.
To original reporter, You need to set XMODIFIERS=@im=kinput2 for workaround. Basically when you start X, the appropriate XMODIFIERS is set by /etc/X11/xinit/xinitrc.d/xinput. but I guess probably your environment is set XMODIFIERS=@im=none. Xlibs has this really cause. Here's ltrace log: XPending(0x08072ad8, 0x08085488, 0xbffed5f8, 0x40150a1d, 0x08073098) = 1 XNextEvent(0x08072ad8, 0xbffed5d0, 0xbffed5f8, 0x40150a1d, 0x08073098) = 0 XtDispatchEvent(0xbffed5d0, 0xbffed5d0, 0xbffed5f8, 0x40150a1d, 2 <unfinished ...> XmbLookupString(0x0809b348, 0xbffed5d0, 0xbffed291, 256, 0xbffed15c) = 0 XFlush(0x08072ad8, 0, 0xbffed658, 0x0804fa7c, 8) = 1 select(5, 0x0806d3a0, 0x0806d420, 0, 0) = 1 XPending(0x08072ad8, 0xbffed5d0, 0xbffed5f8, 0x40150a1d, 2) = 1 XNextEvent(0x08072ad8, 0xbffed5d0, 0xbffed5f8, 0x40150a1d, 2) = 0 XtDispatchEvent(0xbffed5d0, 0xbffed5d0, 0xbffed5f8, 0x40150a1d, 2 <unfinished ...> XUnregisterIMInstantiateCallback(0x08072ad8, 0, 0, 0, 0x08060ad0) = 1 XIMOfIC(0x0809b348, 0, 0, 0x08072ad8, 0) = 0x0809b0c8 XCloseIM(0x0809b0c8, 0, 0, 0x08072ad8, 0) = 1 XtMalloc(1, 0x08060ad0, 0, 0x40169817, 0x08072ad8) = 0x0809b778 XSetLocaleModifiers(0x0809b778, 0, 0, 0x08072ad8, 0x0808dad0) = 0x08090e88 XtFree(0x0809b778, 0, 0, 0x08072ad8, 0x0808dad0) = 0x0809b780 XRegisterIMInstantiateCallback(0x08072ad8, 0, 0, 0, 0x08060ad0 <unfinished ...> --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ AFAIK this is well-known bug, and I don't think kterm has this problem, because of this problem may occurs with a lot of applications depended on Xlibs.
Thanks, I understand now. kterm with both ja_JP and jaJP.eucJP does indeed segfault only if XMODIFIERS="@im=none". Is this Xlibs bug potentially dangerous in any other instances?
Shouldn't the component of this report be changed?
Well, no. I applied a patch to avoid this problem. This problem should be fixed in kterm-6.2.0-28. this version of kterm should not crashes whether XMODIFIERS is set or not. but please note that the appropriate XMODIFIERS is needed for using kinput2.