Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Tue, Jan 15, 2019 at 07:57:30PM -0500, Thomas Dickey wrote:
> On Fri, Jan 04, 2019 at 05:30:22PM -0500, Thomas Dickey wrote:
> > On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote:
> > > Would this warrant to add "affects" tags for firefox and chromium to
> > > this bug? Not sure about the Debian policy here. In this case, the
> > 
> > no - see https://www.debian.org/Bugs/server-control#affects
> > 
> > (since you're the only one to report it so far)
> 
> ...while testing this, I noticed that fc-match also dumps core (same bug).
> 
> Also, the changes I made in #343 had no effect on this bug - still happens
> with the same configuration.

The current version works for me:

https://gitlab.freedesktop.org/tagoh/fontconfig/commit/699d6e4d8415a5d94483ea81fdf277964a33b8f1

See developer's notes in

https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Fri, Jan 04, 2019 at 05:30:22PM -0500, Thomas Dickey wrote:
> On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote:
> > Would this warrant to add "affects" tags for firefox and chromium to
> > this bug? Not sure about the Debian policy here. In this case, the
> 
> no - see https://www.debian.org/Bugs/server-control#affects
> 
> (since you're the only one to report it so far)

...while testing this, I noticed that fc-match also dumps core (same bug).

Also, the changes I made in #343 had no effect on this bug - still happens
with the same configuration.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote:
> Would this warrant to add "affects" tags for firefox and chromium to
> this bug? Not sure about the Debian policy here. In this case, the

no - see https://www.debian.org/Bugs/server-control#affects

(since you're the only one to report it so far)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2019-01-04 01:10]:
> 
> > On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote:
> >> * Thomas Dickey  [2019-01-02 10:46]:
> >> 
> >>> I verified that the same issue exists in current code, and submitted an
> >>> 
> >>>   https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
> >>> 
> >>> with the attached fix.
> >> 
> >> As a side note, visiting that particular page causes both Chromium and
> >> Firefox to crash in a manner that looks similar to what I reported for
> >> xterm. Chromium crashes completely, in Firefox it's just a tab crash.
> > 
> > perhaps the bug will get more attention then :-)
> 
> Would this warrant to add "affects" tags for firefox and chromium to
> this bug? Not sure about the Debian policy here. In this case, the
> Subject line should probably be changed to something more meaningful.

agreed - the subject line is too specific.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2019-01-04 01:10]:

> On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote:
>> * Thomas Dickey  [2019-01-02 10:46]:
>> 
>>> I verified that the same issue exists in current code, and submitted an
>>> 
>>> https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
>>> 
>>> with the attached fix.
>> 
>> As a side note, visiting that particular page causes both Chromium and
>> Firefox to crash in a manner that looks similar to what I reported for
>> xterm. Chromium crashes completely, in Firefox it's just a tab crash.
> 
> perhaps the bug will get more attention then :-)

Would this warrant to add "affects" tags for firefox and chromium to
this bug? Not sure about the Debian policy here. In this case, the
Subject line should probably be changed to something more meaningful.

>> As with the xterm issue, this doesn't occur when I remove either my
>> fonts.conf file or the package fonts-noto-color-emoji.
>> 
>> These two characters appear on the page:
>> 
>> U+1F44D THUMBS UP SIGN
>> U+1F44E THUMBS DOWN SIGN
>> 
>> And the CSS stylesheet seems to load the "Noto Color Emoji" font.
> 
> The fontconfig debug-trace can verify that
> (setting the environment variable FC_DEBUG to 1 gives a trace
> which shows the filename along with other details - much more than 
> XFT_DEBUG=3).

Thanks, this looks useful. In Chromium, it shows that
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf is loaded when
fonts-noto-color-emoji is installed and I visit the page, both with
fonts.conf enabled and disabled. I cannot discern, though, which effect
from fonts.conf triggers the bug.

In Firefox, though, there's no mention of NotoColorEmoji.ttf in the
output!?

>> In Firefox, the crash doesn't happen when I remove the two offending
>> characters from the page source /or/ when I remove the CSS file. In
>> Chromium, only removing the CSS file helps.
>> 
>> So it seems that more packages might be affected? But it's probably best
>> to wait for the provided patch to make it into fontconfig before taking
>> more time to look into this?
>> 
>> For the record, here's the crash report from Firefox (probably not
>> particularly useful due to missing symbols):
>> https://crash-stats.mozilla.com/report/index/afb14dec-e1f6-43dd-8852-d80670190103
>> 
>> And this is what Chromium outputs on the terminal:
>> 
>> Received signal 11 SEGV_MAPERR 
>> #0 0x55ed814cc9d1 
>> #1 0x55ed814cb413 
>> #2 0x55ed814cc945 
>> #3 0x7f59461f86b0 
>> #4 0x7f5942b5c2d1 
>> #5 0x7f5942b5c418 
>> #6 0x7f5942b5d55f FcConfigSubstituteWithPat
>> #7 0x7f5942b6d9bd FcFontRenderPrepare
>> #8 0x7f5942b6de44 FcFontMatch
> 
> That's a different path, but still in the same file.
> 
> Actually when I looked into this, I expected to spend more time finding
> a good solution, but adding the simple fix made the problem go away.
> 
> There are 250/2714 lines in fccfg.h using pointers and the instance here
> dated from April 2012, so there's the potential for several similar bugs.

Running /usr/bin/chromium with the "-g" option and chromium-dbgsym
installed reveals that the crash is on the same line. See the trace
below. If anybody knows how I can get a tab crash report from Firefox
with debug symbols, I could verify that, too.

# Env:
# LD_LIBRARY_PATH=
#
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/local/bin:/usr/local/graphviz-2.14/bin:/home/alex/bin:/opt/local/libexec/perl5.12/sitebin:/usr/local/bin:/usr/local/graphviz-2.14/bin:/home/alex/bin:/opt/local/libexec/perl5.12/sitebin
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension=
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.CtrzY4
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/93/bf1ca108f6cddbc890082782dd02fd1ad96147.debug...done.
done.
(gdb) run
Starting program: /usr/lib/chromium/chromium --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension= --single-process 
[Thread debugging using libthread_db enabled]
Using host 

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Thu, Jan 03, 2019 at 05:42:47PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2018-12-31 20:32]:
> 
> > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> >> * Thomas Dickey  [2018-12-31 00:51]:
> >> 
> >>> Can you make a backtrace for #341, please?
> >> 
> >> Here it is:
> 
> [...]
> 
> Thanks a lot for taking the time to investigate the issue and for
> providing the fontconfig patch! I've been away from home and couldn't
> reply earlier.

The trace was helpful - thanks
> 
> As the issue has now been solved xterm-wise, just a few remarks:
> 
> >> Reading symbols from /usr/bin/xterm...Reading symbols from 
> >> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
> >> done.
> >> (gdb) run -fa 'Noto Mono'
> > 
> > fwiw, my Debian/testing machine has these fonts (with "noto" in their 
> > names):
> > 
> > ii  fonts-noto20181130-1
> > all  metapackage to pull in all Noto fonts
> > ii  fonts-noto-cjk1:20170601+repack1-3  
> > all  "No Tofu" font families with large Unicode 
> > coverage (CJK regular and bold)
> > ii  fonts-noto-color-emoji0~20180810-1  
> > all  color emoji font from Google
> > ii  fonts-noto-hinted 20181130-1
> > all  "No Tofu" font families with large Unicode 
> > coverage (hinted)
> > ii  fonts-noto-mono   20181130-1
> > all  "No Tofu" monospaced font family with large 
> > Unicode coverage
> > ii  fonts-noto-unhinted   20181130-1
> > all  "No Tofu" font families with large Unicode 
> > coverage (unhinted)
> 
> Exactly the same on my system. fonts-noto-color-emoji was only recently
> installed via a dependency at the same time as xterm was upgraded from
> 337 to 338.
> 
> It turns out that simply removing the package fonts-noto-color-emoji
> eliminates the issue! So that's probably the best workaround right now
> for anyone with the same problem, until your patch is incorporated into
> fontconfig.

That'll be a very popular solution :-)
 
> [...]
> 
> > This part is in the newer function which handles fallback fonts.
> > Since your trace shows line-numbers, I'm assuming it's not the Debian 
> > package.
> > (Actually the trace seems to show that you've compiled fontconfig -- turning
> > off the optimization might help pinpoint the details).
> 
> For the record, no, the trace had been made with the provided
> xterm-dbgsym and libfontconfig1-dbgsym packages.

I see (I tried using Debian's debug-symbols quite a while back, but didn't
find them useful enough).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2019-01-02 10:46]:
> 
> > I verified that the same issue exists in current code, and submitted an
> > 
> > https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
> > 
> > with the attached fix.
> 
> As a side note, visiting that particular page causes both Chromium and
> Firefox to crash in a manner that looks similar to what I reported for
> xterm. Chromium crashes completely, in Firefox it's just a tab crash.

perhaps the bug will get more attention then :-)
 
> As with the xterm issue, this doesn't occur when I remove either my
> fonts.conf file or the package fonts-noto-color-emoji.
> 
> These two characters appear on the page:
> 
> U+1F44D THUMBS UP SIGN
> U+1F44E THUMBS DOWN SIGN
> 
> And the CSS stylesheet seems to load the "Noto Color Emoji" font.

The fontconfig debug-trace can verify that
(setting the environment variable FC_DEBUG to 1 gives a trace
which shows the filename along with other details - much more than XFT_DEBUG=3).
 
> In Firefox, the crash doesn't happen when I remove the two offending
> characters from the page source /or/ when I remove the CSS file. In
> Chromium, only removing the CSS file helps.
> 
> So it seems that more packages might be affected? But it's probably best
> to wait for the provided patch to make it into fontconfig before taking
> more time to look into this?
> 
> For the record, here's the crash report from Firefox (probably not
> particularly useful due to missing symbols):
> https://crash-stats.mozilla.com/report/index/afb14dec-e1f6-43dd-8852-d80670190103
> 
> And this is what Chromium outputs on the terminal:
> 
> Received signal 11 SEGV_MAPERR 
> #0 0x55ed814cc9d1 
> #1 0x55ed814cb413 
> #2 0x55ed814cc945 
> #3 0x7f59461f86b0 
> #4 0x7f5942b5c2d1 
> #5 0x7f5942b5c418 
> #6 0x7f5942b5d55f FcConfigSubstituteWithPat
> #7 0x7f5942b6d9bd FcFontRenderPrepare
> #8 0x7f5942b6de44 FcFontMatch

That's a different path, but still in the same file.

Actually when I looked into this, I expected to spend more time finding
a good solution, but adding the simple fix made the problem go away.

There are 250/2714 lines in fccfg.h using pointers and the instance here
dated from April 2012, so there's the potential for several similar bugs.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2019-01-02 10:46]:

> I verified that the same issue exists in current code, and submitted an
> 
>   https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
> 
> with the attached fix.

As a side note, visiting that particular page causes both Chromium and
Firefox to crash in a manner that looks similar to what I reported for
xterm. Chromium crashes completely, in Firefox it's just a tab crash.

As with the xterm issue, this doesn't occur when I remove either my
fonts.conf file or the package fonts-noto-color-emoji.

These two characters appear on the page:

U+1F44D THUMBS UP SIGN
U+1F44E THUMBS DOWN SIGN

And the CSS stylesheet seems to load the "Noto Color Emoji" font.

In Firefox, the crash doesn't happen when I remove the two offending
characters from the page source /or/ when I remove the CSS file. In
Chromium, only removing the CSS file helps.

So it seems that more packages might be affected? But it's probably best
to wait for the provided patch to make it into fontconfig before taking
more time to look into this?

For the record, here's the crash report from Firefox (probably not
particularly useful due to missing symbols):
https://crash-stats.mozilla.com/report/index/afb14dec-e1f6-43dd-8852-d80670190103

And this is what Chromium outputs on the terminal:

Received signal 11 SEGV_MAPERR 
#0 0x55ed814cc9d1 
#1 0x55ed814cb413 
#2 0x55ed814cc945 
#3 0x7f59461f86b0 
#4 0x7f5942b5c2d1 
#5 0x7f5942b5c418 
#6 0x7f5942b5d55f FcConfigSubstituteWithPat
#7 0x7f5942b6d9bd FcFontRenderPrepare
#8 0x7f5942b6de44 FcFontMatch
#9 0x55ed81b8ec63 
#10 0x55ed8032726f 
#11 0x55ed7f794bdc 
#12 0x55ed80326c5c 
#13 0x55ed8151395b 
#14 0x55ed81516204 
#15 0x55ed81517363 
#16 0x55ed81511ba0 
#17 0x55ed81511e8a 
#18 0x55ed8152177f 
#19 0x55ed8141925d 
#20 0x55ed81496f61 
#21 0x55ed814e1e57 
#22 0x55ed814994c3 
#23 0x55ed814908b6 
#24 0x55ed81490d84 
#25 0x55ed814dcec5 
#26 0x7f59461edfa3 start_thread
#27 0x7f593def988f clone
  r8: 7f5900177110  r9: 7f5900177110 r10: 0003 r11: 
0020
 r12: 55ed88462528 r13: 7f590002cad0 r14: 7f59000690a0 r15: 
0001
  di: 7f590002cad0  si: 7f59000690a0  bp: 55ed88312ba0  bx: 
0003
  dx: 0001  ax: 55ed88312b70  cx:   sp: 
7f590f7fbb40
  ip: 7f5942b5c2d1 efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2018-12-31 20:32]:

> On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
>> * Thomas Dickey  [2018-12-31 00:51]:
>> 
>>> Can you make a backtrace for #341, please?
>> 
>> Here it is:

[...]

Thanks a lot for taking the time to investigate the issue and for
providing the fontconfig patch! I've been away from home and couldn't
reply earlier.

As the issue has now been solved xterm-wise, just a few remarks:

>> Reading symbols from /usr/bin/xterm...Reading symbols from 
>> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
>> done.
>> (gdb) run -fa 'Noto Mono'
> 
> fwiw, my Debian/testing machine has these fonts (with "noto" in their names):
> 
> ii  fonts-noto20181130-1  
>   all  metapackage to pull in all Noto fonts
> ii  fonts-noto-cjk1:20170601+repack1-3
>   all  "No Tofu" font families with large Unicode coverage 
> (CJK regular and bold)
> ii  fonts-noto-color-emoji0~20180810-1
>   all  color emoji font from Google
> ii  fonts-noto-hinted 20181130-1  
>   all  "No Tofu" font families with large Unicode coverage 
> (hinted)
> ii  fonts-noto-mono   20181130-1  
>   all  "No Tofu" monospaced font family with large Unicode 
> coverage
> ii  fonts-noto-unhinted   20181130-1  
>   all  "No Tofu" font families with large Unicode coverage 
> (unhinted)

Exactly the same on my system. fonts-noto-color-emoji was only recently
installed via a dependency at the same time as xterm was upgraded from
337 to 338.

It turns out that simply removing the package fonts-noto-color-emoji
eliminates the issue! So that's probably the best workaround right now
for anyone with the same problem, until your patch is incorporated into
fontconfig.

[...]

> This part is in the newer function which handles fallback fonts.
> Since your trace shows line-numbers, I'm assuming it's not the Debian package.
> (Actually the trace seems to show that you've compiled fontconfig -- turning
> off the optimization might help pinpoint the details).

For the record, no, the trace had been made with the provided
xterm-dbgsym and libfontconfig1-dbgsym packages.

Best
Alex

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Tue, Jan 01, 2019 at 06:59:59PM -0500, Thomas Dickey wrote:
> On Tue, Jan 01, 2019 at 12:28:38PM -0500, Thomas Dickey wrote:
> > On Mon, Dec 31, 2018 at 02:32:58PM -0500, Thomas Dickey wrote:
> > > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> > > > * Thomas Dickey  [2018-12-31 00:51]:
> > > > 
> > > > > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > > > > ...
> > > > >> 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
> > > > > 
> > > > > Can you make a backtrace for #341, please?
> > > > 
> > > > Here it is:
> > > 
> > > thanks.  I added some notes, but have not been able to reproduce the 
> > > problem.
> > 
> > Looking at this again, I saw (using XFT_DEBUG=3 and the -report-fonts 
> > option)
> > that the fallback was using unifont.  Removing that got it to break (I'll
> > see whether the bug lies in Xft or fontconfig, at least).
> 
> The latter.   Here's a fix for fontconfig that eliminates this particular 
> crash.
...
I verified that the same issue exists in current code, and submitted an

https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140

with the attached fix.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
diff --git a/src/fccfg.c b/src/fccfg.c
index a87dfec..5c275c4 100644
--- a/src/fccfg.c
+++ b/src/fccfg.c
@@ -978,7 +978,7 @@ FcConfigEvaluate (FcPattern *p, FcPattern *p_pat, FcMatchKind kind, FcExpr *e)
 FcValue	v, vl, vr, vle, vre;
 FcMatrix	*m;
 FcChar8 *str;
-FcOp	op = FC_OP_GET_OP (e->op);
+FcOp	op = e ? FC_OP_GET_OP (e->op) : FcOpNil;
 FcValuePromotionBuffer buf1, buf2;
 
 switch ((int) op) {


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Tue, Jan 01, 2019 at 06:59:59PM -0500, Thomas Dickey wrote:
> On Tue, Jan 01, 2019 at 12:28:38PM -0500, Thomas Dickey wrote:
> > On Mon, Dec 31, 2018 at 02:32:58PM -0500, Thomas Dickey wrote:
> > > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> > > > * Thomas Dickey  [2018-12-31 00:51]:
> > > > 
> > > > > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > > > > ...
> > > > >> 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
> > > > > 
> > > > > Can you make a backtrace for #341, please?
> > > > 
> > > > Here it is:
> > > 
> > > thanks.  I added some notes, but have not been able to reproduce the 
> > > problem.
> > 
> > Looking at this again, I saw (using XFT_DEBUG=3 and the -report-fonts 
> > option)
> > that the fallback was using unifont.  Removing that got it to break (I'll
> > see whether the bug lies in Xft or fontconfig, at least).
... 
> (The bug should be reassigned to the libfontconfig1 package).

fwiw, attaching a screenshot showing xterm working as designed for this
configuration, and the scripts used for running the test.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
#!/bin/sh
make||exit
rm -vf *core*
export LD_LIBRARY_PATH=/usr/build/xterm/fontconfig-2.13.1/src/.libs
# libfontconfig.so.1.12.0
ldd xterm
FC_DEBUG=8191
XFT_DEBUG=3 ./xterm -xrm '*showMissingGlyphs:true' -report-fonts -fa 'Noto Mono'
#!/bin/bash
tput bold
printf '\U1f384!'
tput smul
printf '\U1f384!'
tput sgr0
printf '\U1f384!'
echo done

/usr/bin/printf "\U0001F384\tU+1F384 CHRISTMAS TREE\n"
/usr/bin/printf "\U0001F385\tU+1F385 FATHER CHRISTMAS\n"
/usr/bin/printf "\U0001F3E1\tU+1F3E1 HOUSE WITH GARDEN\n"
/usr/bin/printf "\U0001F644\tU+1F644 FACE WITH ROLLING EYES\n"
/usr/bin/printf "\U0001F601\tU+1F601 GRINNING FACE WITH SMILING EYES\n"
/usr/bin/printf "\U0001F604\tU+1F604 SMILING FACE WITH OPEN MOUTH AND SMILING 
EYES\n"


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Tue, Jan 01, 2019 at 12:28:38PM -0500, Thomas Dickey wrote:
> On Mon, Dec 31, 2018 at 02:32:58PM -0500, Thomas Dickey wrote:
> > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> > > * Thomas Dickey  [2018-12-31 00:51]:
> > > 
> > > > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > > > ...
> > > >> 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
> > > > 
> > > > Can you make a backtrace for #341, please?
> > > 
> > > Here it is:
> > 
> > thanks.  I added some notes, but have not been able to reproduce the 
> > problem.
> 
> Looking at this again, I saw (using XFT_DEBUG=3 and the -report-fonts option)
> that the fallback was using unifont.  Removing that got it to break (I'll
> see whether the bug lies in Xft or fontconfig, at least).

The latter.   Here's a fix for fontconfig that eliminates this particular crash.

--- fontconfig-2.13.1/src/fccfg.c.orig  2019-01-01 17:05:49.0 -0500
+++ fontconfig-2.13.1/src/fccfg.c   2019-01-01 18:56:05.547070797 -0500
@@ -978,9 +978,14 @@
 FcValuev, vl, vr, vle, vre;
 FcMatrix   *m;
 FcChar8 *str;
-FcOp   op = FC_OP_GET_OP (e->op);
+FcOp   op;
 FcValuePromotionBuffer buf1, buf2;
 
+if (e == 0) {
+   op = FcOpNil;
+} else {
+   op = FC_OP_GET_OP (e->op);
+}
 switch ((int) op) {
 case FcOpInteger:
v.type = FcTypeInteger;

(The bug should be reassigned to the libfontconfig1 package).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Mon, Dec 31, 2018 at 02:32:58PM -0500, Thomas Dickey wrote:
> On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> > * Thomas Dickey  [2018-12-31 00:51]:
> > 
> > > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > > ...
> > >> 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
> > > 
> > > Can you make a backtrace for #341, please?
> > 
> > Here it is:
> 
> thanks.  I added some notes, but have not been able to reproduce the problem.

Looking at this again, I saw (using XFT_DEBUG=3 and the -report-fonts option)
that the fallback was using unifont.  Removing that got it to break (I'll
see whether the bug lies in Xft or fontconfig, at least).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2018-12-31 00:51]:
> 
> > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > ...
> >> 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
> > 
> > Can you make a backtrace for #341, please?
> 
> Here it is:

thanks.  I added some notes, but have not been able to reproduce the problem.
 
> Reading symbols from /usr/bin/xterm...Reading symbols from 
> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
> done.
> (gdb) run -fa 'Noto Mono'

fwiw, my Debian/testing machine has these fonts (with "noto" in their names):

ii  fonts-noto20181130-1
all  metapackage to pull in all Noto fonts
ii  fonts-noto-cjk1:20170601+repack1-3  
all  "No Tofu" font families with large Unicode coverage (CJK 
regular and bold)
ii  fonts-noto-color-emoji0~20180810-1  
all  color emoji font from Google
ii  fonts-noto-hinted 20181130-1
all  "No Tofu" font families with large Unicode coverage 
(hinted)
ii  fonts-noto-mono   20181130-1
all  "No Tofu" monospaced font family with large Unicode 
coverage
ii  fonts-noto-unhinted   20181130-1
all  "No Tofu" font families with large Unicode coverage 
(unhinted)

> Starting program: /usr/bin/xterm -fa 'Noto Mono'
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
> p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
> (gdb) bt full
> #0  0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
> p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
> v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i = 
> 1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, 
> c = 0x556f1ad0, f = 0x556f1ad0, 
> l = 0x556f1ad0, r = 0x556f1ad0}}
> vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
> c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
> vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
> c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
> vle = 
> vre = 
> m = 
> str = 
> op = 

If "op" weren't optimized, we could see which case is breaking :-)
But since "e" is null, that says op is garbage anyway.

> buf1 = {u = {d = 0, i = 0, l = 0, 
> c = 
> "\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
> buf2 = {u = {d = 0, i = 0, l = 0, 
> c = 
> "\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
>  '\000' , "\a\000\000\000\000\000\000\000 
> \000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
>  '\000' , "[\000\000\000w", '\000' , 
> "n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
>  '\000' , "\260\377\377\377\377\377\377\377"...}}
> #1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430, 
> p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont, 
> e=e@entry=0x55681218) at fccfg.c:1003
> m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx = 
> 1.4821969375237396e-323, yy = 1}
> xx = 
> yy = 
> xy = 
> yx = 
> v = {type = FcTypeMatrix, u = {s = 0x3  at address 0x3>, i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, 
> f = 0x3, l = 0x3, r = 0x3}}
> vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", 
> i = 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 
> 0x556f24b0, c = 0x556f24b0, f = 0x556f24b0, 

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2018-12-31 00:51]:

> On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> ...
>> 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
> 
> Can you make a backtrace for #341, please?

Here it is:


Reading symbols from /usr/bin/xterm...Reading symbols from 
/usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556f2430, p_pat=0x559dea90, 
kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0  0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i = 
1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, c 
= 0x556f1ad0, f = 0x556f1ad0, 
l = 0x556f1ad0, r = 0x556f1ad0}}
vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c 
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c 
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle = 
vre = 
m = 
str = 
op = 
buf1 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , "[\000\000\000w", '\000' , 
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
 '\000' , "\260\377\377\377\377\377\377\377"...}}
#1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430, 
p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont, 
e=e@entry=0x55681218) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx = 
1.4821969375237396e-323, yy = 1}
xx = 
yy = 
xy = 
yx = 
v = {type = FcTypeMatrix, u = {s = 0x3 , i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, f = 
0x3, l = 0x3, r = 0x3}}
vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", i 
= 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 0x556f24b0, 
c = 0x556f24b0, f = 0x556f24b0, 
l = 0x556f24b0, r = 0x556f24b0}}
vr = {type = FcTypeString, u = {s = 0x77d660a4 
 
"\205\300\017\224\300\017\266\300\351\267\375\377\377L\211\346H\211\327\350\364=",
 i = -136945500, b = -136945500, 
d = 6.9533490418283141e-310, m = 0x77d660a4 
, c = 0x77d660a4 , f = 
0x77d660a4 , 
l = 0x77d660a4 , r = 0x77d660a4 
}}
vle = 
vre = 
m = 
str = 
op = FcOpMatrix
buf1 = {u = {d = 4.6355706048940074e-310, i = 1432998448, l = 
93824993579568, 
c = 
"0\322iUUU\000\000\002\000\000\000\000\000\000\000\060\026jUUU\000\000\354c\326\367\377\177\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\003",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000UU\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , 
"\f\341\327\367\377\177\000\000\000\000\000\000\257\060\000\000\000\240\316\365\301\035?\376\003\000\000\000\000\000\000\000\256\340\327\367\377\177\000\000\200\326\377\377\264\060\000\000\000"...}}
buf2 = {u = {d = 4.6355706320533889e-310, i = 1433548160, l = 
93824994129280, 
c = 
"\200\065rUUU\000\000\270\220B\365\377\177\000\000\000\000\000\000\000\000\000\000\362H\327\367\377\177\000\000
 ", '\000' , 

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2018-12-30 23:14]:

> On Sun, Dec 30, 2018 at 10:15:53PM +0100, Sven Joachim wrote:
>> On 2018-12-30 18:26 +0100, Alexander Meyer wrote:
>>> 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.

For the record: I disabled/enabled my fonts.conf by moving it out of
~/.config/fontconfig/ and then back inside. I did not set FONTCONFIG_FILE.

Also, as described in my original report, the segfault is not limited to
"Noto Mono" but seems to happen with any other font, too. (I've randomly
tried a few from my fc-list.)

>> | 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.

Please find attached the gzipped output of

$ XFT_DEBUG=1023 xterm -fa 'Noto Mono'

with xterm 341. All output happens directly after startup, there's no
output after issuing the command that displays the character that causes
the segfault.

Best
Alex


xterm-341-XFT_DEBUG_1023.log.gz
Description: application/gzip

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
...
> 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

Can you make a backtrace for #341, please?

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

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  [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 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Sven Joachim]

Control: unmerge -1
Control: reopen -1

On 2018-12-30 18:26 +0100, Alexander Meyer wrote:

> * Sven Joachim  [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

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
...
> 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

In a quick check, this doesn't give me a problem.

It might depend on the available fonts, and if (as in the other problem)
it's due to some specific font you might be able to get some useful
information by turning on Xft's debug trace (setting the environment
variable XFT_DEBUG to 1023 turns on _everything_).

...at the moment I'm working on lynx, but if there's something that I
can reproduce on this, will do that.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Sven Joachim  [2018-12-29 19:20]:

> On 2018-12-21 20:54 +0100, Alexander Meyer wrote:
> 
>> * Sven Joachim  [2018-12-21 20:38]:
>> 
>>> On 2018-12-21 20:16 +0100, Alexander Meyer wrote:
>>> 
 I've found a bug report from Arch Linux that looks similar:
 https://bugs.archlinux.org/task/61115

[...]

>>> I could also still reproduce it, that's why I did not close #916349 in
>>> the xterm 340-1 upload.
>> 
>> I couldn't tell whether that bug was the same as mine, as none of the
>> error messages mentioned there came up for me, also that bug doesn't
>> talk about segfaulting.
> 
> Oh, indeed.  But neither does the Archlinux bug report, it only mentions
> the dreadful "X Error of failed request" which aborts xterm.

That's right, indeed. Maybe mentioning the Arch Linux report caused
confusion rather than it helped. I'm sorry.

> And I could reproduce that with xterm 338 trough 340, but not your
> segfault.
> 
>> If you think this is the same bug, then feel free to merge, of course.
> 
> 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. To be honest, I know
next to nothing about fontconfig or font handling in X. I've installed
that file some years ago without knowing what it actually does because
it made some fonts look nicer in Firefox etc. and happened to have no
ill side effects until now. Maybe I could even get along without it, but
that wouldn't resolve this bug, of course.

Best
Alex

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Sven Joachim]

On 2018-12-21 20:54 +0100, Alexander Meyer wrote:

> * Sven Joachim  [2018-12-21 20:38]:
>
>> On 2018-12-21 20:16 +0100, Alexander Meyer wrote:
>> 
>>> Package: xterm
>>> Version: 340-1
>>> Severity: important
>>> [...]
>>> I've found a bug report from Arch Linux that looks similar:
>>> https://bugs.archlinux.org/task/61115
>> 
>> Strange that you looked in the Arch bugtracker, but apparently not in
>> the Debian BTS…
>
> That came up via a web search as I had originally thought the bug had to
> do with mutt.
>
>>> But the last comment there claims the bug disappeared in 340 which is not 
>>> the
>>> case for me.
>> 
>> I could also still reproduce it, that's why I did not close #916349 in
>> the xterm 340-1 upload.
>
> I couldn't tell whether that bug was the same as mine, as none of the
> error messages mentioned there came up for me, also that bug doesn't
> talk about segfaulting.

Oh, indeed.  But neither does the Archlinux bug report, it only mentions
the dreadful "X Error of failed request" which aborts xterm.  And I
could reproduce that with xterm 338 trough 340, but not your segfault.

> If you think this is the same bug, then feel free to merge, of course.

If you still get a segfault in xterm 341 (uploaded today), please tell
me and I will unmerge and reopen your bug.

Cheers,
   Sven

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Sven Joachim  [2018-12-21 20:38]:

> On 2018-12-21 20:16 +0100, Alexander Meyer wrote:
> 
>> Package: xterm
>> Version: 340-1
>> Severity: important
>> [...]
>> I've found a bug report from Arch Linux that looks similar:
>> https://bugs.archlinux.org/task/61115
> 
> Strange that you looked in the Arch bugtracker, but apparently not in
> the Debian BTS…

That came up via a web search as I had originally thought the bug had to
do with mutt.

>> But the last comment there claims the bug disappeared in 340 which is not the
>> case for me.
> 
> I could also still reproduce it, that's why I did not close #916349 in
> the xterm 340-1 upload.

I couldn't tell whether that bug was the same as mine, as none of the
error messages mentioned there came up for me, also that bug doesn't
talk about segfaulting.

If you think this is the same bug, then feel free to merge, of course.

Thanks
Alex

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Sven Joachim]

Control: merge 916349 -1

On 2018-12-21 20:16 +0100, Alexander Meyer wrote:

> Package: xterm
> Version: 340-1
> Severity: important
> [...]
> I've found a bug report from Arch Linux that looks similar:
> https://bugs.archlinux.org/task/61115

Strange that you looked in the Arch bugtracker, but apparently not in
the Debian BTS…

> But the last comment there claims the bug disappeared in 340 which is not the
> case for me.

I could also still reproduce it, that's why I did not close #916349 in
the xterm 340-1 upload.

Cheers,
   Sven

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

Package: xterm
Version: 340-1
Severity: important

Dear Maintainer,

after updating from 337-1 to 338-1 in testing, xterm crashes with a segfault
when certain Unicode characters appear in the buffer. This only happens when I
have selected a font using the -fa option. It doesn't seem to matter which font
it is. (I've randomly tried a few from my fc-list.)

I've installed 340-1 from unstable, but the bug persists.

As I came across this issue while reading mails in mutt, I've tried to identify
the exact characters causing it. It turned out that these commands cause the
crash:

$ /usr/bin/printf "\U0001F384"# U+1F384 CHRISTMAS TREE
$ /usr/bin/printf "\U0001F385"# U+1F385 FATHER CHRISTMAS
$ /usr/bin/printf "\U0001F3E1"# U+1F3E1 HOUSE WITH GARDEN
$ /usr/bin/printf "\U0001F644"# U+1F644 FACE WITH ROLLING EYES

Whereas these commands work fine:

$ /usr/bin/printf "\U0001F601"# U+1F601 GRINNING FACE WITH SMILING EYES
$ /usr/bin/printf "\U0001F604"# U+1F604 SMILING FACE WITH OPEN MOUTH 
AND SMILING EYES

To reproduce this bug, run one of the aforementioned commands after starting
xterm with e.g.

$ xterm -fa 'Noto Mono'

When leaving out -fa, xterm doesn't crash.

Please find below a backtrace.

As the bug was introduced after updating xterm (libfontconfig1 remained
untouched during that update), I'm filing this under xterm for the time being.

xterm 337-1 doesn't crash. Interestingly, though, in 337-1 all six
above-mentioned characters are not displayed at all when running with e.g.
-fa 'Noto Mono'. I just see a two-glyph-wide blank space. Whereas in 338-1 and
340-1, the two non-crashing characters U+1F601 and U+1F604 are actually
displayed.

I've found a bug report from Arch Linux that looks similar:
https://bugs.archlinux.org/task/61115
But the last comment there claims the bug disappeared in 340 which is not the
case for me.

I don't know a great deal about X font handling, so in case you need more info,
please try to explain in detail what you need to know. Thanks in advance. Also,
I don't care that much if those special glyphs are actually displayed correctly
in my xterm or not, it's just that xterm shouldn't crash.


Backtrace:

Reading symbols from /usr/bin/xterm...Reading symbols from 
/usr/lib/debug/.build-id/e1/82f855c9d3aa8701e44c1fc1d41e81eb0b0bd6.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556fdfd0, 
p_pat=0x559ea680, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0  0x77d662d1 in FcConfigEvaluate (p=0x556fdfd0, 
p_pat=0x559ea680, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556fd670 "\300\326oUUU", 
i = 1433392752, b = 1433392752, d = 4.6355706243752135e-310, 
m = 0x556fd670, c = 0x556fd670, f = 0x556fd670, 
l = 0x556fd670, r = 0x556fd670}}
vl = {type = 1433007920, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436460672, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle = 
vre = 
m = 
str = 
op = 
buf1 = {u = {d = 0, i = 0, l = 0, 
c = "\000\000\000\000\000\000\000\000 
\326oUUU\000\000H\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\320\325oUUU\000\000`\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\200\325oUUU\000\000x\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000\340\324oUUU\000\000\250\367iUUU\000\000\000\000\000\000\000\000\000\000\025",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , "[\000\000\000w", '\000' , 
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
 '\000' , "\260\377\377\377\377\377\377\377"...}}
#1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556fdfd0, 
p_pat=p_pat@entry=0x559ea680, kind=kind@entry=FcMatchFont, 
e=e@entry=0x55683b38) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, 
  yx =