Issue 6759

Summary: OO displays garbage window and icon names in CDE
Product: Internationalization Reporter: jkeil <jk>
Component: codeAssignee: christof.pintaske
Status: CLOSED NOT_AN_OOO_ISSUE QA Contact: issues@l10n <issues>
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 1.0.0   
Target Milestone: ---   
Hardware: Sun   
OS: Solaris   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Snapshot showing broken window names in the DE ISO8869-15 locale on Solaris / CDE
none
A small test program that reproduces the problem
none
Updated sopatchlevel.sh & Solaris READMEs, check for required libX11 patches on Solaris8 none

Description jkeil 2002-08-05 10:04:48 UTC
OS: Solaris 8 2/2002 (x86) and Solaris 8 FCS + MU7 (SPARC)
Relevant(?) patches: 108773-13 (sparc) or 108774-13 (x86)


OO 1.0.1 sometimes displays garbage characters as the title
used in CDE window decorations and in CDE icon names.  I can
reproduce this when logged into a CDE session that uses
the 'de_DE.ISO8859-15' locale. 

The same problem exists in SO 6.0 PP1.


relevant 'xprop' information for two OO 1.0.1 windows:

1. empty text document window (should have the name "unbenannt1
   - OpenOffice.org 1.0.1 "
     
% xprop | egrep '_NAME|_LOCALE'
WM_LOCALE_NAME(STRING) = "de_DE..ISO8859-15"
WM_ICON_NAME(STRING) =
"\37777777765\37777777756\37777777742\37777777745\37777777756\37777777741\37777777756\37777777756\37777777764\37777777661\37777777640\37777777655\37777777640\37777777717\37777777760\37777777745\37777777756\37777777717\37777777746\37777777746\37777777751\37777777743\37777777745\37777777656\37777777757\37777777762\37777777747\37777777640\37777777661\37777777656\37777777660\37777777656\37777777661\37777777640"
WM_NAME(STRING) =
"\37777777765\37777777756\37777777742\37777777745\37777777756\37777777741\37777777756\37777777756\37777777764\37777777661\37777777640\37777777655\37777777640\37777777717\37777777760\37777777745\37777777756\37777777717\37777777746\37777777746\37777777751\37777777743\37777777745\37777777656\37777777757\37777777762\37777777747\37777777640\37777777661\37777777656\37777777660\37777777656\37777777661\37777777640"


2. a dialog box that opens when clicking "Einfügen" -> "Manueller
   Umbruch..."  (this window should use the name "Umbruch
   einfügen"):

% xprop | egrep '_NAME|_LOCALE'
WM_LOCALE_NAME(STRING) = "de_DE..ISO8859-15"
WM_ICON_NAME(STRING) =
"\37777777725\37777777755\37777777742\37777777762\37777777765\37777777743\37777777750\37777777640\37777777745\37777777751\37777777756\37777777746|\37777777747\37777777745\37777777756"
WM_NAME(STRING) =
"\37777777725\37777777755\37777777742\37777777762\37777777765\37777777743\37777777750\37777777640\37777777745\37777777751\37777777756\37777777746|\37777777747\37777777745\37777777756"


I'll append a snapshot showing the broken window names of the above two
windows, when running on Solaris / CDE.
Comment 1 jkeil 2002-08-05 10:07:46 UTC
Created attachment 2436 [details]
Snapshot showing broken window names in the DE ISO8869-15 locale on Solaris / CDE
Comment 2 jkeil 2002-08-05 10:33:13 UTC
I've tried to look into this problem and have found out, that
apparently the
use of the '__XOpenIM' subroutine from the
/usr/openwin/lib/locale/common/xiiimp.so.2
shared library causes this problem.  When running on Solaris, OO tries to
dlopen() the above mentioned shared library, looks up the  '__XOpenIM'
symbol in it and calls this function ( function XvaOpenIM() in file
vcl/unx/source/app/i18n_wrp.cxx ).


There's alternate code in OO that just calls the X11 documented function
'XOpenIM()' instead.  This is enabled by running OO 1.0.x with the
environment variable USE_XOPENIM defined to some value.  When running
OO with
 
  env USE_XOPENIM=1 ~/OpenOffice.org1.0.1/soffice

the problem does *not* occur any more and xprop for the same two windows
mentioned in the initial bug report shows:

% xprop |egrep '_NAME|_LOCALE'
WM_LOCALE_NAME(STRING) = "de_DE..ISO8859-15"
WM_ICON_NAME(STRING) = "unbenannt1 - OpenOffice.org 1.0.1 "
WM_NAME(STRING) = "unbenannt1 - OpenOffice.org 1.0.1 "

% xprop | egrep '_NAME|_LOCALE'
WM_LOCALE_NAME(STRING) = "de_DE..ISO8859-15"
WM_ICON_NAME(STRING) = "Umbruch einf\37777777774gen"
WM_NAME(STRING) = "Umbruch einf\37777777774gen"



As far as I can tell, the use of '__XOpenIM' frees some memory inside the
Solaris X11 shared library that is still in use by the X11 character set
conversion routines. Or in other words: the X11 character set conversion
routines operate on freed memory, after __XOpenIM was called.

These character set conversion routines are used by
XmbTextListToTextProperty
( in WMAdaptor::setWMName() in file vcl/unx/source/app/wmadaptor.cxx ) and
it seems they still access memory that was freed by the use of
'__XOpenIM'.
Comment 3 christof.pintaske 2002-08-05 11:14:33 UTC
good job ! though the problem is not really with __XOpenIM but with
Xlib changing the X locale in a running process, your evaluation is
superbe. The XWindow patch 108652-56 should fix the problem.
Comment 4 jkeil 2002-08-05 11:31:17 UTC
Created attachment 2437 [details]
A small test program that reproduces the problem
Comment 5 jkeil 2002-08-05 11:45:40 UTC
Yes, Patch-ID# 108652-56 has fixed this problem on SPARC. 

(I guess that the fix for "4663998 In ko/zh/ja locales, Asian
characters becomes garbage in dtmail & dtcm" is relevant here)

Unfortunatelly the x86 version of the same patch is not yet released.


I've attached a small X11 program (wmname.c) that reproduces the issue.
It converts the text "Umbruch einfügen" twice using
XmbTextListToTextProperty, before and after calling __XOpenIM(). The
second call returns garbage:

% wmname
0 characters not converted
converted text: Umbruch einfügen
0 characters not converted
converted text: Õíâòõãè åéîæ|çåî


Using my solaris shared library version of the "Electric Fence"
malloc debug tool 
(http://www.tools.de/solaris/ElectricFence-2.0.5-solaris.tar.gz)
we see the access to the freed memory:

% truss -t\!all -SSEGV env LD_PRELOAD=efence.so EF_ALLOW_MALLOC_0=1
EF_PROTECT_FREE=1 wmname

  Electric Fence 2.0.5 Copyright (C) 1987-1995 Bruce Perens.
0 characters not converted
converted text: Umbruch einfügen
    Incurred fault #6, FLTBOUNDS  %pc = 0xDF880B67
      siginfo: SIGSEGV SEGV_MAPERR addr=0xDF6D6FF0
    Received signal #11, SIGSEGV [default]
      siginfo: SIGSEGV SEGV_MAPERR addr=0xDF6D6FF0


% pstack `pgrep wmname`
16190:  wmname
 df880b67 mbtocs   (de811ff8, 8046ff0, 8046ff8, 8046f88, 8046b84,
8046b38, 1) + 17b
 df880d72 mbstocs  (de811ff8, 8046ff0, 8046ff8, 8046f88, 8046b84,
8046b80, 1) + 52
 dfb5fddc indirect_convert (de80dff8, 8046ff0, 8046ff8, 8046ffc,
8046ff4, 0, 0) + b8
 dfb6011f _XlcConvert (de80dff8, 8046ff0, 8046ff8, 8046ffc, 8046ff4,
0, 0) + 2b
 dfb64170 _XTextListToTextProperty () + 258
 dfb64296 _XmbTextListToTextProperty (df6c0ff4, df7b9ac0, 80470dc, 1,
3, 80470cc) + 2e
 dfb44b91 XmbTextListToTextProperty (df7b9ac0, 80470dc, 1, 3, 80470cc,
80470cc, 1910, dfa36624) + 35
 080508de main     (1, 804710c, 8047114) + aa
 080506db _start   () + 57


The example run of wmname is on S8 x86 where the relevant libX11.so
patch is not yet available.  On S8 SPARC with 108652-56 installed
the test program runs (with and without) "Electric Fence" without
error.
Comment 6 jkeil 2002-08-05 12:02:20 UTC
Minor correction:  the S8 x86 version of the patch is there as well.

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108653

still shows the old -44 rev of the patch but the download of the
signed patch gets you the -46 rev which fixes the issue (in OO 1.0.1,
SO 6.0 PP1 and my "wmname" test program).
Comment 7 Dieter.Loeschky 2002-08-06 13:56:38 UTC
DL->CP: Would you please takeover?
Comment 8 jkeil 2002-08-06 14:16:48 UTC
The question is: does this need fixing at all in OO?  Apparently it's a
problem with Solaris 8's libX11 or maybe the combination of the
__XOpenIM/xiiimp.so.2 and libX11.  It can be fixed by installing the
appropriate OS patches.

Maybe the sopatchlevel.sh script should be extended a bit to not only
check the version of the installed C++ shared library, but also the
version of the xiiimp.so.2 and libX11.so shared library.

Plus updating the patch requirements for Solaris 8 (SPARC/x86) in the
README* files ...
Comment 9 jkeil 2002-08-07 10:56:57 UTC
Created attachment 2450 [details]
Updated sopatchlevel.sh & Solaris READMEs, check for required libX11 patches on Solaris8
Comment 10 christof.pintaske 2002-08-07 11:21:31 UTC
not a gsl issue (not an OOo issue). 

I cannot recommend to check for patch 108652. All patches below -49
are fine and all patches above -56 are too. The problem occures only
when IIIMP is installed and patched with 108773. The patch is big and
replaces almost all of your XServer installation. 
Having this patch as a pre-requisite would be a pain unless you really
have a problem. 

Nevertheless mentioning the problem in the README should be fine.
Comment 11 Unknown 2002-08-09 11:53:08 UTC
CP: can I change the assignment to you? 
Comment 12 christof.pintaske 2002-08-14 12:06:53 UTC
not a gsl issue
Comment 13 michael.bemmer 2003-03-12 14:16:37 UTC
As mentioned on the qa dev list on March 5th I will close all resolved
<wontfix/duplicate/worksforme/invalid> issues. Please see this posting for
details. First step in IssueZilla is unfortunately to set them to verified.
Comment 14 michael.bemmer 2003-03-12 14:17:09 UTC
As mentioned on the qa dev list on March 5th I will close all resolved
<wontfix/duplicate/worksforme/invalid> issues. Please see this posting for
details. First step in IssueZilla is unfortunately to set them to verified.
Comment 15 michael.bemmer 2003-03-12 14:35:00 UTC
As mentioned on the qa dev list on March 5th I will close all resolved
<wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.