|
Bugzilla – Full Text Bug Listing |
| Summary: | xterm takes all available memory and crashes | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Björn Voigt <bjoernv> |
| Component: | X.Org | Assignee: | Stefan Dirsch <sndirsch> |
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | dickey, dickey |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | i386 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Hmm ... I cannot reproduce this problem. Notwithstanding the iso-8859-15, it's loading the iso-10646 font. I don't see the locale given for this problem. I encountered and fixed one (not recent) issue during post-204 changes which would cause it to crash in this manner when there's no matching bold font (I saw it in the largest font setting for uxterm). Essentially the fix for this is to remove the recursion of xtermLoadFont() (two places in fontutils.c). That recursion was used to recover from a lesser problem of the font server a few years ago. (I'm expecting to close out patch #205 today). Indeed. The output of "locale" should be attached. Thanks for the hint to xterm patch #205! no problem. I might have forgetten that bug except for noticing the iso-10646 font. I stumbled into it when testing the geometry changes for toolbar support. The locale output is: $ locale LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= But then you shouldn't use a iso8859-15 font. Use the iso-10646 one instead. True, but anyway, xterm should not crash, if a font in a different locale is used. I would prefer a patch for xterm (see comment #2). I've just updated to xterm #205 for SUSE Linux 10.1. Therefore I close this as FIXED now. I'm not happy with the fact, that normal SuSE users should wait 1/2 year (likely release date for SuSE Linux 10.1) for this patch. openSUE 10.1 alpha will be available pretty soon. http://www.opensuse.org/Welcome_to_openSUSE.org [...] Sep 29 SUSE Linux 10.1 alpha1 It will include the new xterm package. Björn> I'm not happy with the fact, that normal SuSE users should wait 1/2 Björn> year (likely release date for SuSE Linux 10.1) for this patch. But the problem you encountered won't happen anyway as long as you don't do something stupid like using a ISO-8859-15 font in a UTF-8 locale. I.e. "normal SuSE users" won't encounter this bug. One scenario where normal users encounter this bug: 1) user modifies his $HOME/.Xdefaults (ISO-8859-15 font for xterm on a ISO-8859-15 system) 2) root backups home-directories and may be some other directories 3) root installs the new SuSE Linux 10 with the default UTF-8 locale 4) root restores /home 5) user's xterm crashes You are right of course that in this scenario xterm should not crash. The font settings are wrong and if xterm does not crash it will still display garbage, but if it crashes it is difficult to find out what is wrong. |
The xterm of 10.0 RC1 seems to have a problem. In my setup (10.0 RC1 upgraded from 9.3) xterm takes all available memory after some seconds, slows down the system and crashes after some minutes before showing a window. My .Xdefaults contains (this fonts are available in 10.0 RC1): XTerm*font: -adobe-courier-*-r-*-*-18-*-*-*-*-*-iso8859-15 XTerm*boldFont: -adobe-courier-*-r-*-*-18-*-*-*-*-*-iso8859-15 It is interesting, that "xterm -fn '-adobe-courier-*-r-*-*-18-*-*-*-*-*-iso8859-15'" crashes, but "xedit -fn '-adobe-courier-*-r-*-*-18-*-*-*-*-*-iso8859-15'" works. Also "xtern -fn fixed" works. So, xterm has probably problems with some fonts. This are some lines of "strace -o logfile xterm": ... read(3, 0xbfef2b64, 32) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], NULL, NULL, NULL) = 1 (in [3]) read(3, "\1\0\255\10\244\1\0\0\375\377\1\0\v\0\376\377\367\377\0"..., 32) = 32 read(3, "\5\0\0\0\240X\321\20\0\0\377\0\0\0\33\0\0\0\0\0\16\0\4"..., 40) = 40 read(3, "\263\0\0\0\26\2\0\0@\0\0\0\27\2\0\0\264\0\0\0\370\1\0\0"..., 216) = 216 read(3, "\0\0\t\0\v\0\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 1424) = 1424 write(3, "-\0\17\0\314\3\240\3.\0\17\0-adobe-courier-*-r-*"..., 72) = 72 read(3, 0xbfef2b64, 32) = -1 EAGAIN (Resource temporarily unavailable) ... "ltrace -o logfile xterm" shows this: ... strlen("-Adobe-Courier-bold-R-*-*-18-180"...) = 44 strlen("-Adobe-Courier-bold-R-*-*-18-180"...) = 44 strcat("-Adobe-Courier-bold-R-*-*-18-180"..., "ISO10646-1") = "-Adobe-Courier-bold-R-*-*-18-180"... XLoadQueryFont(0x80964e8, 0x81bbf50, 200, 8, 0) = 0x81bbfd8 XFreeFont(0x80964e8, 0x81bbfd8, 200, 8, 0) = 1 XLoadQueryFont(0x80964e8, 0x80b2034, 3, 8, 0) = 0x81bbfd8 __strcpy_chk(0xbff1b7e8, 0x80b2034, 200, 8, 0) = 0xbff1b7e8 XLoadQueryFont(0x80964e8, 0x80b1ff4, 200, 8, 0) = 0x81be528 strlen("-adobe-courier-*-r-*-*-18-*-*-*-"...) = 46 malloc(47) = 0x81b95d8 strcpy(0x81b95d8, "-adobe-courier-*-r-*-*-18-*-*-*-"...) = 0x81b95d8 XLoadQueryFont(0x80964e8, 0x80afe54, 200, 8, 0 <unfinished ...> ...