On Sun, Dec 30, 2018 at 10:15:53PM +0100, Sven Joachim wrote: > Control: unmerge -1 > Control: reopen -1 > > On 2018-12-30 18:26 +0100, Alexander Meyer wrote: > > > * Sven Joachim <svenjoac@gmx.de> [2018-12-29 19:20]: > >> > >> If you still get a segfault in xterm 341 (uploaded today), please tell > >> me and I will unmerge and reopen your bug. > > > > Unfortunately, I still get the same segfault with 341. But I've just > > noticed that the behaviour changes depending on whether I have a > > fonts.conf file enabled or not. > > > > I normally use the fonts.conf file from > > https://gist.github.com/dcrystalj/d1c1ceacf0d6fc9a0556 > > installed in ~/.config/fontconfig/fonts.conf > > > > This is the behaviour I get across xterm versions: > > (everything with libfontconfig1 2.13.1-2) > > > > fonts.conf enabled: > > 337: works > > 338: segfault > > 340: segfault > > 341: segfault > > > > fonts.conf disabled: > > 337: works > > 338: aborts with error message "BadLength (poly request too large or > > internal Xlib length error)" as described in bug 916349 > > 340: works! (as opposed to what is reported in bug 916349) > > 341: works > > > > > > So the segfault only happens with that fonts.conf. > > Thanks, that explains why others did not see it - and possibly also why > I could still reproduce #916349 in xterm 340, as I have my own > fonts.conf, albeit a much shorter and simpler one than yours. > > Alas, with your file (saved as /tmp/fonts.conf) xterm does not even start > here, although I have fonts-noto-mono and fonts-noto-color-emoji > installed: If xterm sees the latter, it will not start. That's a problem that can only be solved by modifying Xft. Not xterm. But the short term goal is to get xterm working as well as feasible with Xft before moving on to see what can be done to make Xft handle the color bitmap fonts. I'm looking for details on how to reproduce the segmentation violation which was reported. > ,---- > | $ FONTCONFIG_FILE=/tmp/foo/fonts.conf xterm -fa 'Noto Mono' Back up a step: with that fonts.conf, I get no result for fc-match 'Noto Mono' while without it, I do get a match. A quick look at strace tells me that setting FONTCONFIG_FILE eliminates a lot of the normal configuration information, and probably isn't what you want to do in reproducing the problem. > | xterm: cannot match normal font "Noto Mono" > | xterm: Selected font has no non-zero height for ISO-8859-1 encoding ...and because there's no match, for _this_ case I get the same failure. However, that's not a bug (in xterm), but a problem with configuration. > So I am a bit at a loss here. And I am definitely not a an expert on > fontconfig (or fonts in general) either. I'd like to see the XFT_DEBUG information from the known broken scenario. If it tells me that Xft is still loading the color-noto font, there's probably nothing that I can do to address that in xterm. -- Thomas E. Dickey <dickey@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net
Attachment:
signature.asc
Description: Digital signature