Control: unmerge -1 Control: reopen -1 On 2018-12-30 18:26 +0100, Alexander Meyer wrote:
> * Sven Joachim <svenj...@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: ,---- | $ FONTCONFIG_FILE=/tmp/foo/fonts.conf xterm -fa 'Noto Mono' | xterm: cannot match normal font "Noto Mono" | xterm: Selected font has no non-zero height for ISO-8859-1 encoding `---- So I am a bit at a loss here. And I am definitely not a an expert on fontconfig (or fonts in general) either. Cheers, Sven
