Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 83769 - xemacs hangs with UTF-8 locale
Summary: xemacs hangs with UTF-8 locale
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: XEmacs team
URL:
Whiteboard:
Keywords:
: 108686 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-01 21:19 UTC by Christian Vogler
Modified: 2016-08-25 20:58 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Vogler 2005-03-01 21:19:33 UTC
This affects version 21.4.15-r3, possibly others. This bug is reproducible on AMD64, as well.

When my locale is set to LANG=en_US.UTF-8, xemacs brings up the main window and then freezes for a long time. Eventually, after 15-20 seconds, the console window spits out the following: Warning: Missing charsets in String to FontSet conversion, and only then the xemacs window becomes responsive to user input.

Setting the locale to plain C or en_US is a workaround, but this is not really a good option.

Reproducible: Always
Steps to Reproduce:
1. From the bash: export LANG=en_US.UTF-8 (make sure it is in the /etc/locales.build list)
2. Start xemacs, and observe the main window hang.


Actual Results:  
xemacs hangs for 15-20 seconds.

Expected Results:  
Start up immediately, like it does with non-UTF locales.

Note: the same bug also occurs on an AMD x86_64 system, and a Xeon i686 system.

Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5,
glibc-2.3.4.20040808-r1, 2.4.26-gentoo-r9 i686)
=================================================================
System uname: 2.4.26-gentoo-r9 i686 AMD Athlon(tm) MP
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4
(#1, Feb 26 2005, 18:39:59)]
dev-lang/python:     2.2.3-r5, 2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.4.19-r1, 2.4.22-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-mp -O2 -fomit-frame-pointer -ftracer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config
/usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config
/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb
/usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-mp -O2 -fomit-frame-pointer -ftracer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS=" ftp://ftp.ussg.iu.edu/pub/linux/gentoo"
LANG="en_US.UTF-8"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aalib alsa apm arts avi berkdb bitmap-fonts bonobo cdr crypt cscope
cups curl dvd emboss encode esd f77 fam flac font-server foomaticdb fortran
gdbmgif gnome gphoto2 gpm gtk gtk2 gtkhtml guile imagemagick imlib ipv6 java
jpeg junit kde ldap leim libg++ libwww mad mbox mikmod motif mozilla mpeg mule
mysql ncurses nls oggvorbis opengl pam pdflib perl png python qt quicktime
readline ruby samba sdl slang speex spell sse ssl svga tcltk tcpd tetex tiff
truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
Comment 1 Christian Vogler 2005-03-03 08:52:22 UTC
The following link may be pertinent to this bug. If so, it hints at a wider issue with Xorg, and consequently, this bug should be reassigned to Xorg. Further testing revealed that a lot of other X applications are affected, such as Xfig, xedit, etc.

https://bugs.freedesktop.org/show_bug.cgi?id=2475
Comment 2 Christian Vogler 2005-03-03 09:04:38 UTC
Yes, that seems to be the problem. Emerging the intlfonts package and adding /usr/share/fonts/intlfonts to the font path greatly alleviated the problem. There is still a brief, strange 100% CPU spike when the X applications in question are started, so it looks as if there is something else still going on, but the startup times are now bearable.
Comment 3 Jonathan Hudson 2005-07-16 02:51:10 UTC
I've seen this off and on. After upgrading to freetype-2.1.10, xemacs would
crash and take out the X server (either 6.8.2-rc2 or 6.8.99.14) --- see #99089.

After removing almost all fonts, it's back to the massive CPU/long pause mode of
startup. 

IMHO, there's some strange interaction between xemacs + UTF8 + current freetype
+ current x.org, which I'd guess no one package is going to solve.

Cross posted to #99089.

Comment 4 Jonathan Hudson 2005-07-16 08:20:41 UTC
(In reply to comment #3)
> I've seen this off and on. After upgrading to freetype-2.1.10, xemacs would
> crash and take out the X server (either 6.8.2-rc2 or 6.8.99.14) --- see #99089.
> 
> After removing almost all fonts, it's back to the massive CPU/long pause mode of
> startup. 
> 
> IMHO, there's some strange interaction between xemacs + UTF8 + current freetype
> + current x.org, which I'd guess no one package is going to solve.
> 
> Cross posted to #99089.
> 
> 


And reverting to freetype 2.1.9-r1 fixes everything, no crashes, no pauses.
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2006-06-05 11:52:33 UTC
*** Bug 108686 has been marked as a duplicate of this bug. ***
Comment 6 Hans de Graaff gentoo-dev Security 2006-12-10 01:52:13 UTC
One possible way to work around this in Gentoo is to make xemacs depend on intlfonts when the mule USE flag is selected. Even if that doesn't fix the problem it makes it a lot less bearable. Any comments on this proposed solution? If not then I'll commit this to portage in a week or so.

From what I can tell from discussion on the xemacs-beta mailing list xemacs does some pretty weird and outdated things with fonts due to the mule way of handling multiple character sets, so that may easily cause these issues. This won't be fixed, instead efforts in 21.5 are focused on getting better UTF-8 support. 
Comment 7 SpanKY gentoo-dev 2008-03-18 02:30:54 UTC
this is prob a dupe of Bug 71747
Comment 8 Jonas Stein gentoo-dev 2016-08-24 22:15:51 UTC
any news? Can we close it?
Comment 9 Mats Lidell gentoo-dev 2016-08-25 20:58:39 UTC
Thanks for bringing this to my attention. I can't reproduce the issue using current xemacs-21.4.24.ebuild so I will close it.