Bug 124960 - [PATCH] XmTextField: "Character xxx not supported in font" errors, bug in multibyte code
Summary: [PATCH] XmTextField: "Character xxx not supported in font" errors, bug in mul...
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openmotif   
(Show other bugs)
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
Depends On:
Blocks: 116727
TreeView+ depends on / blocked
Reported: 2004-06-01 16:34 UTC by Brad Despres
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-08 16:11:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tar file containing test case and fix (20.00 KB, application/octet-stream)
2004-06-01 16:37 UTC, Brad Despres
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:243 normal SHIPPED_LIVE Updated OpenMotif packages fix several bugs 2004-09-01 04:00:00 UTC

Description Brad Despres 2004-06-01 16:34:44 UTC
RedHat Enterprise Linux 3.0 with Motif 2.2.2 gets the following errors
all over the place:
       Name: textField                                     
       Class: XmTextField                                  
       Character '\163' not supported in font.  Discarded. 

Below I have included a C file and a Makefile for a test case.
Also I provided a suggested fix for the problem.

This problem has been reported to Motifzone/ICS as bug # 1257.


Test case to illustrate bug in PrintableString in TextF.c in Motif 2.2.2.

How to test:
  setenv LANG en_US.UTF-8 (or another multibyte lang)

  The following error messages will appear:

       Name: textField                                     
       Class: XmTextField                                  
       Character '\163' not supported in font.  Discarded. 
       Name: textField                                     
       Class: XmTextField                                  
       Character '\157' not supported in font.  Discarded. 

  If you do not see the errors, try setting LANG to another multibyte
encoding, such as ja_JP.ujis.

The test case makes a simple GUI with a XmTextField widget and
puts a regular single-byte string into it.
The bug causes the text field to reject the string character by
character and print the error messages.

The bug is new for Motif 2.2 and was not present in Motif 2.1.
The error lies in a new block of code added to the end of
PrintableString in TextF.c:

    tmp_str = (wchar_t *)str;
    ret_val = wctomb(tmp, *tmp_str);
    count = 0;
    while ( (ret_val > 0)&& (buf_size >= MB_CUR_MAX) && (count < n) )
        count += 1;
        tmp += ret_val;
        buf_size -= ret_val;
        ret_val = wctomb(tmp, *tmp_str);
    if (ret_val == -1)    /* bad character */
      return (False);
    is_printable = XTextWidth(TextF_Font(tf), cache_ptr, tmp - cache_ptr);

The problem is that ValidateString passes the address of a single
wchar_t tmp.
The str parameter in PrintableString is consequently set to &tmp.
n is passed in as 1.
str is copied to tmp_str.
The code runs wctomb on *tmp_str, increments tmp_str and then calls wctomb
on *tmp_str again.
At this point tmp_str points to other stuff on the stack - whatever
happens to
occupy &tmp+1.

I (think I) fixed the problem by changing the code to:

   tmp_str = (wchar_t *)str;
   count = 0;
   do {
     ret_val = wctomb(tmp, *tmp_str);
     count += 1;
     tmp += ret_val;
     buf_size -= ret_val;
   } while ( (ret_val > 0)&& (buf_size >= MB_CUR_MAX) && (count < n) ) ;
   if (ret_val == -1)    /* bad character */
     return (False);
   is_printable =
     ( XTextWidth(TextF_Font(tf), cache_ptr, tmp - cache_ptr) != 0 ) ;

Apparently RedHat does not define SUPPORT_ZERO_WIDTH in their version
of Motif.

The bug does not always show itself.
Depending on the libXm build, sometimes the address at &tmp+1 is another
variable, and other times it is just uninitialized junk.
This test case attempts to write gibberish to the stack area, so that the
bug will show up in the case that &tmp+1 is not used by another variable.
If another variable lands on &tmp+1, then the problem is revealed only if
this other variable is set to something that wctomb doesn''t like.
I built Motif 2.2.2 on RHLinux8 and the &tmp+1 address was given to
the start_tmp variable.
The pointer value given to start_tmp did not cause wctomb to complain,
so this test case didn''t reveal the problem on RH8.
The test case shows the problem with RedHat Enterprise Linux 3.0.

This test case is intended to run on a 32 bit Intel platform.
It may not work on other platforms.

Brad Despres

all: textf_bug

textf_bug: textf_bug.c
	cc -g -Wall \
		-I/usr/X11R6/include \
		textf_bug.c \
		-o textf_bug \
		-L/usr/X11R6/lib \
		-lXm \
		-lXp \
		-lXt \
		-lXext \
		-lXpm \
		-lSM \
		-lICE \
		-lX11 \

	-rm -f textf_bug textf_bug.o

#include <locale.h>
#include <Xm/TextF.h>
int main (
  int argc ,
  char * argv []
  Widget toplevel , textf ;
  XtAppContext app ;
  int i , fill_size = 1024 ;
  unsigned char fill_byte = 0xA5 ;
  unsigned fill_pattern ;
  unsigned * pu ;

  /* Read the locale env variables. */
  setlocale ( LC_ALL , "" ) ;

  toplevel = XtVaAppInitialize ( & app , "TestCase" , NULL , 0 ,
    & argc , argv , NULL , NULL ) ;

  textf = XtVaCreateWidget ( "textField" ,
    xmTextFieldWidgetClass , toplevel ,
    NULL ) ;
  XtManageChild ( textf ) ;

  { /*
     * Write jibberish into the unused area below the stack.
     * Hopefully this will cause the bug to show up.

    /* Push a variable so we know where the sp is. */
    unsigned u ;

    /* Set up the fill pattern, e.g. 0xA5A5A5A5 */
    memset ( ( void * ) & fill_pattern , fill_byte , sizeof ( u ) ) ;

    /* Fill the unused stack area with this pattern. */
    for ( i = 0 , pu = & u ; i < fill_size ; i ++ , pu -- ) {
      * pu = fill_pattern ;
      /* The problem is masked if you fill it with zeros instead. */
  XmTextFieldSetString ( textf , "some text" ) ;
  XtRealizeWidget ( toplevel ) ;
  XtAppMainLoop ( app ) ;

  /* Not reached. */
  return ( 0 ) ;

Comment 1 Brad Despres 2004-06-01 16:37:58 UTC
Created attachment 100748 [details]
tar file containing test case and fix

Comment 2 Thomas Woerner 2004-06-03 14:45:18 UTC
I agree, your patch seems to solve the problem in TextF. I will
contract ICS to get their estimation.

In the meantime: Please have a look at


This is the new OpenMotif 2.2.3 version with a patch for #124960 and
#124961. If ICS gives the ok for these patches, this version will
become the next update.

Comment 3 Brad Despres 2004-06-03 17:56:49 UTC
Hi Thomas Woerner.  Thank you so much for your quick respose :)

From where should we tell our customers to get the latest openmotif
from RedHat?
Should we point them to your http://people.redhat.com/twoerner site?

Will openmotif-2.2.3-2 and subsequent versions be available through
the RedHat update channel for Enterprise 3?

Comment 4 Thomas Woerner 2004-06-04 08:38:08 UTC
This package will be released as a erratum for RHEL3, if there are no
problems with it and if ICS gives the ok for the patches.

Please keep in mind that the packages on my people site are test versions.

Comment 5 Thomas Woerner 2004-06-08 16:11:16 UTC
ICS gave the ok, here are the final packages, that will be in U3:


It has an additional patch for a popup timeout problem: #123027

Comment 6 Jay Turner 2004-09-02 02:21:38 UTC
An errata 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.


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