Summary: | x11-terms/xterm-201 uses cpu 100% when opening | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Webert <rockoo> |
Component: | [OLD] Core system | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | dickey, fonts, kamensky.fb, rockoo, somercet, x11 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Daniel Webert
2005-04-28 11:47:59 UTC
This is a problem with XPRINT, and the Xt (XToolkit) libraries. XTerm has had this problem with the SimpleMenus for quite a while, and now it has spread to the general terminal window as well. Before, XTerm started properly, but opening a SimpleMenu would drag my Athlon 900/256MB RAM system to its knees. After the menus first appeared, though, the problem did not occur again. ANY OTHER XTerm run concurrently or not, however, would would display the same CPU-churn, and again, only once. "Warning: Missing charsets in String to FontSet conversion" is the standard (Xt) error given after a slow startup. As of xterm-201, this problem appears when the XTerm is first launched. Once the CPU hogging ceases, XTerm is fully functional, and the menus operate normally. So has been moved "up". This is not necessarily a client bug, or even a client's bug-invoking call; it is the X server consuming 98% of CPU, and the suck continues after killing the XTerm. Some X.org standard apps, e.g., xman(1), display this behavior (and error message) as well. bitmap(1) does not. The XPRINT mozdev web pages mention that xman and other apps (but not bitmap) have been updated to their wonderful new XPRINT system. Some Mozilla developer said the above error means that certain fonts are missing. Since ISO-10646 is 31-bits big, minus dead space, I have no doubt that is the case. Odd that this makes one's system unuable, though. Or that xorg-x11 simply doesn't require the necessary fonts. (My system USES type1-fonts, truetype-fonts, and has the free MS fonts installed in /usr/local/share/fonts.) I am recompiling X11 with USE="-xprint". I will monitor this bug report. Thank you. Thomas, I think I need your help/input/feedback on these issues :) I haven't observed this - but your comment regarding SimpleMenu is a clue. (SimpleMenu works on all of the systems I have for test). The toolbar configuration builds all of the (3) menus at startup. If as you say invoking a SimpleMenu would (before) max out the CPU, doing it 3 times at startup won't help much. From the comments about X.Org, it sounds as if someone broke the Athena (Xaw) library. Are the menus using some unusual font? Rockoo, got response? I was wrong. ;-) XPRINT has nothing to do with the bug I've described. Here is some more info, if it will help. I'll try some more things soon.... 11:57 PM ~ $ LD_PROFILE=libXaw.so.8 /usr/bin/xman Warning: Missing charsets in String to FontSet conversion 12:02 AM ~ $ sprof -p libXaw.so.8 Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 40.00 0.02 0.02 0 0.00 XawLabelResize 20.00 0.03 0.01 2 5000.00 _XawTextPrepareToUpdate 20.00 0.04 0.01 1 10000.00 XawInitializeDefaultConverters 20.00 0.05 0.01 0 0.00 XawTextSrcClassInitialize 0.00 0.05 0.00 15 0.00 XawTextSourceFindAnchor 0.00 0.05 0.00 14 0.00 XawTextSourceAnchorAndEntity 0.00 0.05 0.00 14 0.00 XawTextSourceNextAnchor 0.00 0.05 0.00 12 0.00 XawInitializeWidgetSet 0.00 0.05 0.00 8 0.00 XawTextSourceRead 0.00 0.05 0.00 8 0.00 _XawImGetShellHeight 0.00 0.05 0.00 8 0.00 _XawImResizeVendorShell 0.00 0.05 0.00 6 0.00 _XawTextNeedsUpdating 0.00 0.05 0.00 5 0.00 XawDialogAddButton 0.00 0.05 0.00 5 0.00 XawVendorShellExtResize 0.00 0.05 0.00 5 0.00 _XawImInitialize 0.00 0.05 0.00 4 0.00 XawAddPixmapLoader 0.00 0.05 0.00 4 0.00 XawTextGetInsertionPoint 0.00 0.05 0.00 4 0.00 XawTextSinkFindDistance 0.00 0.05 0.00 4 0.00 XawTextSinkInsertCursor 0.00 0.05 0.00 3 0.00 XawTextSourceScan 0.00 0.05 0.00 3 0.00 XawTipEnable 0.00 0.05 0.00 3 0.00 _XawImRealize 0.00 0.05 0.00 2 0.00 XawTextSinkFindPosition 0.00 0.05 0.00 2 0.00 XawTextSinkMaxLines 0.00 0.05 0.00 2 0.00 _XawTextBuildLineTable 0.00 0.05 0.00 2 0.00 _XawTextExecuteUpdate 0.00 0.05 0.00 2 0.00 _XawTextFormat 0.00 0.05 0.00 2 0.00 _XawTextSetLineAndColumnNumber 0.00 0.05 0.00 2 0.00 _XawTextSetScrollBars 0.00 0.05 0.00 1 0.00 XawPixmapsInitialize 0.00 0.05 0.00 1 0.00 XawTextDisableRedisplay 0.00 0.05 0.00 1 0.00 XawTextEnableRedisplay 0.00 0.05 0.00 1 0.00 XawTextSinkMaxHeight 0.00 0.05 0.00 1 0.00 XawTextSinkSetTabs 0.00 0.05 0.00 1 0.00 XawTextSourceAddAnchor 0.00 0.05 0.00 1 0.00 _XawGetPageSize 0.00 0.05 0.00 1 0.00 _XawImRegister 0.00 0.05 0.00 1 0.00 _Xaw_atowc I've seen the missing-charsets message before (usually on systems where it's set in the desktop resources - not under my control). It might be related to the layout problem. Also I see in this report a reference to version 8 of Xaw (the last I knew about was 7). Perhaps as I suggest, someone's broken the library, e.g., by trying to improve its layout algorithm. "appres XTerm" might show the font information. I've experienced this bug as well, and not only with that version of xterm. But I've just managed to fix it. The problem is this: andreas@laptop ~ $ ls -l /usr/share/fonts/fonts lrwxrwxrwx 1 root root 1 2 maj 18.41 /usr/share/fonts/fonts -> . That symlink causes xterm and other programs to go into an endless loop (that they abort after 5 seconds for some reason) while searching for fonts. Removing the symlink fixed the problem for me. I don't know why the symlink is there in the first place, maybe its used by something else. I hope this helps in fixing this problem . something like this (errno) probably terminates it: 90 ELOOP Number of symbolic links encountered during path name traversal exceeds MAXSYMLINKS Stray links like that are usually a result of install-script bugs. Adding the X11 and fonts teams (which have a significant overlap in personnel, so sorry about the double emails to you folks) to this bug -- maybe they've seen the symlink issue? Yeah it's a duplicate. I don't have time atm but if you search for bugs w/ /usr/share/fonts/fonts that are open assigned to x11, you'll find it. ok people, xterm-202 in portage now. please try and report, unless thomas previously stated on this bug that 203 would bear the fix. As Donnie noted above, this isn't an xterm issue, it's an xorg + gentoo issue. Marking as duplicate. *** This bug has been marked as a duplicate of 89743 *** I don't have that symlink, but xterm still takes up the whole cpu on startup Me, too. It seems to be unicode related: $time LC_ALL=en_US xterm -e true real 0m0.126s user 0m0.038s sys 0m0.017s $ time LC_ALL=en_US.utf8 xterm -e true Warning: Missing charsets in String to FontSet conversion real 0m13.955s user 0m0.111s sys 0m0.021s And I get the error message mentioned in comment #1 as well. Problem is gone after downgrade from 202 to 200-r3. I think I have a fix. Check to see that USE flag "cjk" is enabled for x11-base/xorg-x11. Without that, you apparently lose a lot of base fonts for Asian glyphs. This does not affect xterm (I can display Nordic Runes (!) without it) but it does seem to mess with Xaw/Xt, which xterm uses ONLY for the Control-<mouse-button> menus. "cjk" seems to be a flag with two uses. Mutt uses it to enable extra fonts, allowing it to display many languages regardless of the terminal support, but Mutt with flag "-cjk" will display many languages, regardless, if the terminal and locale support them. xorg-x11, on the other hand, uses it to enable fonts and base functionality for some libraries. So "cjk" becomes an odd flag: if you have it enabled for X11 and use Mutt primarily via xterm/konsole et alia then you don't want or need "cjk" for Mutt itself. Perhaps it needs to be split into "cjk" for X11, consolefonts and the rest and "cjk-extra" for applications such as Mutt that come with extra, orthogonal capability. |