Bug 165798 - Can't input wide-characters with a UTF-8 locale
Summary: Can't input wide-characters with a UTF-8 locale
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: newt
Version: 4.0
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
: ---
Assignee: Petr Rockai
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
 
Reported: 2005-08-12 12:44 UTC by Bastien Nocera
Modified: 2015-01-08 00:10 UTC (History)
7 users (show)

Fixed In Version: RHBA-2006-0154
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-07 18:27:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Screenshot-Terminal.png (25.67 KB, image/png)
2005-08-12 12:44 UTC, Bastien Nocera
no flags Details
newt-entry-double-free.patch (427 bytes, patch)
2005-11-14 11:45 UTC, Bastien Nocera
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0154 0 normal SHIPPED_LIVE newt bug fix update 2006-03-06 05:00:00 UTC

Description Bastien Nocera 2005-08-12 12:44:34 UTC
newt-0.51.6-5

Can't input Japanese text in entries with LANG=ja_JP.UTF-8, but works fine with
LANG=ja_JP.eucJP

Testing (working):
1) Install the newt sources, and compile them
2) Install the gtk-hiragana-input from http://sourceforge.net/cvs/?group_id=52573
3) Launch "LANG=ja_JP.eucJP gnome-terminal --disable-factory -e ./test"
4) Select the "Hiragana Transliterated" input method
5) Try to type in some text

Testing (not working):
Same thing, but 3) should be "LANG=ja_JP.UTF-8 gnome-terminal --disable-factory
-e ./test"

At 3), the terminal should be in Japanese.

The problem comes from entry.c, in entryHandleKey():
      default:
       if ( (key >= 0x20 && key <= 0x7e) || (key >= 0xa0 && key <= 0xff) ) {

Making this test an "if (1)" will show the same problem as bug #68728 (see
attached screenshot).

Comment 1 Bastien Nocera 2005-08-12 12:44:34 UTC
Created attachment 117670 [details]
Screenshot-Terminal.png

Comment 11 Petr Rockai 2005-11-07 15:01:53 UTC
If you have access, could you try what behaviour exhibits the current devel  
(rawhide) version of newt in the above scenario? I suspect this should be  
fixed there, maybe apart from the if(...) part, where we still disallow a  
range of bytes. Commenting this out should however give correct result, unless  
the width computation is still incorrect (it got fixed for utf-8 in that  
version though, and it works with eg czech/utf8 (it didn't really work 
before)). 

Comment 19 Bastien Nocera 2005-11-14 11:44:28 UTC
The test program (included in the sources) crashes with a double-free, with the
0.51.6-6.unofficial.rhel4 package:
#0  0x080606b1 in kill ()
#1  0x0806042c in raise ()
#2  0x080607c0 in abort ()
#3  0x0806cb57 in __libc_message ()
#4  0x08071c91 in _int_free ()
#5  0x08071f6f in free ()
#6  0x0804bec6 in entryDraw (co=0x9a00f50) at entry.c:213
#7  0x0804a97d in newtDrawForm (co=0x9a002c8) at form.c:608
#8  0x0804b18f in newtFormRun (co=0x9a002c8, es=0xbfec2c58) at form.c:911
#9  0x08048936 in main () at test.c:127

You're trying to free the output of alloca(), allocated line 212.
The package seems to work in my limited testing once you've removed that
unneeded free.

Comment 20 Bastien Nocera 2005-11-14 11:45:12 UTC
Created attachment 121019 [details]
newt-entry-double-free.patch

Comment 34 Red Hat Bugzilla 2006-03-07 18:27:44 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0154.html



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