Bug 62304

Summary:	(Japanese i18n) kterm segmentation fault
Product:	[Retired] Red Hat Public Beta	Reporter:	Warren Togami <wtogami>
Component:	kterm	Assignee:	Nakai <ynakai>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	skipjack-beta2	CC:	petersen, tagoh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-04-17 09:16:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	61590

Description Warren Togami 2002-03-29 13:38:43 UTC

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

Comment 1 Warren Togami 2002-04-06 01:06:10 UTC

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 09:15:08 UTC

I can't reproduce this.

Comment 3 Warren Togami 2002-04-15 09:32:49 UTC

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-17 02:24:41 UTC

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 08:30:26 UTC

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 09:13:02 UTC

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 09:16:54 UTC

Shouldn't the component of this report be changed?

Comment 8 Akira TAGOH 2002-04-17 17:42:49 UTC

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.