Created attachment 2436 [details]
Snapshot showing broken window names in the DE ISO8869-15 locale on Solaris / CDE

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'.

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.

Created attachment 2437 [details]
A small test program that reproduces the problem

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.

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).

DL->CP: Would you please takeover?

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 ...

Created attachment 2450 [details]
Updated sopatchlevel.sh & Solaris READMEs, check for required libX11 patches on Solaris8

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.

CP: can I change the assignment to you? 

not a gsl issue

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.

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.

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.