GNOME Bugzilla – Bug 66174
while remote displaying, g_open_iconv can't find the proper codeset
Last modified: 2004-12-22 21:47:04 UTC
g_open_iconv fail when remote displaying to a linux box from the solaris box with HEAD gtk without libiconv. it doesn't seem to be able to find at the proper codeset... This is reproducible with gtk+/tests/testgtk : DISPLAY=linux-box:0.0 ./testgtk [...] testgtk (pid:16359): ** ERROR **: file basic-x.c: line 287 (find_converter): assertion failed: (cd != (GIConv)-1) aborting... This problem doesn't seem to occur if libiconv compiled in.
Probably the effect of remote display on this is the set of fonts that are present. I'd guess that you ended up needing some characters from a font in an encoding that either Solaris doesn't have iconv() support for or that the name isn't handled by glib/glib/libcharset/config.charset. Knowing what characters set it was trying to find would be useful - you should be able to do this either by running in a debugger or adding a printf. basic-x.c should probably handle the case of not being able to find a converter by simply ignoring the existance of the font.
The crash occurs because we're missing two entries in charset.alias for "ISO-8859-3" and "EUC-CN" on solaris. Adding the entries for these two in the installed charset.alias file has prevented the crash for me. I confirmed both testgtk and testtext are displaying well on the remore linux Xserver after the change. As code fix, I think we'll need to add the entry for "ISO8859-3" in glib/libcharset/config.charset for "solaris", but for "EUC-CN", the actual entry for gb2312 charset is "GB2312". Can we touch pango's table-big.i to change "EUC-CN" to "GB2312"? Also, I have one more question. Once all necessary converters were succefully loaded when I modified the charset.alias and ran testgtk once, I found the problem is completely gone. I mean, even if removed the ENC-CN and ISO8859-3 entries, I cannot see any crash, since neither EUC-CN nor ISO8859-3 converter is loaded any more. Is there any cache for this be created in pango code and saved somewhere in file system?
Changing tables-big.i to refer to GB2312 looks right. As for the caching - there is a root window property PANGO_COVERAGE_WINDOW which points to a cache of coverage information which might be causing this problem. ID=`xprop -root -notype PANGO_COVERAGE_WIN | awk '{ print $5 }'` xkill -id $ID xprop -root -remove PANGO_COVERAGE_WIN (The last xprop shouldn't be necessary, but is a little tidier)
I'd like to check in the change below: pango: * modules/basic/tables-big.i: change "EUC-CN" to "GB2312" the canonical name for gb2312.1980 charset used in libcharset. (#66174) glib: * glib/libcharset/config.charset (os): add ISO8859-3 for Solaris. (#66174) (It seems that there is a problem in glib/libcharset/Makefile.am. when charset.alias is re-installed, I had to do 'gmake uninstall' first.Can you take a look and fix?)
Commit the fix. Erwann, please verify.