Bug 62304 - (Japanese i18n) kterm segmentation fault
(Japanese i18n) kterm segmentation fault
Product: Red Hat Public Beta
Classification: Retired
Component: kterm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nakai
David Lawrence
Depends On:
Blocks: 61590
  Show dependency treegraph
Reported: 2002-03-29 08:38 EST by Warren Togami
Modified: 2007-04-18 12:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-17 05:16:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2002-03-29 08:38:43 EST
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)

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.

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:
Comment 1 Warren Togami 2002-04-05 20:06:10 EST
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. 
Comment 2 Jens Petersen 2002-04-15 05:15:08 EDT
I can't reproduce this.
Comment 3 Warren Togami 2002-04-15 05:32:49 EDT
Re-tested again.  Now when I run "LANG=ja_JP kterm", it crashes when I hit 
SHIFT-SPACE five times.
Comment 4 Jens Petersen 2002-04-16 22:24:41 EDT
Hmmm, I can't reproduce this with kinput2, skkinput, or no XIM client,
no matter how many time I press shift-space.
Comment 5 Akira TAGOH 2002-04-17 04:30:26 EDT
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.
Comment 6 Warren Togami 2002-04-17 05:13:02 EDT
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?
Comment 7 Warren Togami 2002-04-17 05:16:54 EDT
Shouldn't the component of this report be changed?
Comment 8 Akira TAGOH 2002-04-17 13:42:49 EDT
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.

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