Fluxbox div0 crash with Emoji Color One font

[sillysloft]

When starting up fluxbox with the Emoji Color One font installed and enabled in fonts.conf with a config similar to https://github.com/eosrei/emojione-color-font/issues/17#issuecomment-196067631, fluxbox (1.3.7 as well as latest git master) will crash:

[ 4596.656211] traps: fluxbox[7621] trap divide error ip:55e879c247fe sp:7fff6c4186f0 error:0
[ 4596.656214]  in fluxbox[55e879b0b000+15b000]

stacktrace from gdb indicates that it tries to divide by zero:

(gdb) bt
#0  0x0000564e905397fe in FbTk::XftFontImp::load (this=0x564e90ad1330, name="monospace") at src/FbTk/XftFontImp.cc:82
#1  0x0000564e90511950 in FbTk::Font::load (this=this@entry=0x564e90abe358, name="__DEFAULT__") at src/FbTk/Font.cc:227
#2  0x0000564e905124f6 in FbTk::Font::Font (this=0x564e90abe358, name=0x564e90543528 <FbTk::Font::DEFAULT_FONT> "__DEFAULT__")
    at src/FbTk/Font.cc:142
#3  0x0000564e9046d61f in FbTk::ThemeItem<FbTk::Font>::ThemeItem (altname="Window.Font", name="window.font", tm=...,
    this=0x564e90abe310) at src/FbTk/Theme.hh:182
#4  FbWinFrameTheme::FbWinFrameTheme (this=0x564e90abddf0, screen_num=0, extra=".focus", altextra=".Focus")
    at src/FbWinFrameTheme.cc:49
#5  0x0000564e90492dd8 in BScreen::BScreen (this=0x564e90abccc0, rm=..., screenname="session.screen0",
    altscreenname="session.Screen0", scrn=0, num_layers=<optimized out>, opts=3) at src/Screen.cc:198
#6  0x0000564e904cb12b in Fluxbox::Fluxbox (this=0x564e90a94390, argc=<optimized out>, argv=<optimized out>, dpy_name=...,
    rc_path=..., rc_filename=..., xsync=false) at src/fluxbox.cc:416
#7  0x0000564e904485a2 in main (argc=1, argv=0x7ffe57aa5e68) at src/main.cc:208

Relevant source code:

    unsigned int tw = textWidth("WW", 2);
    m_maxlength = 0x8000 / tw;

Reported by: ge0rg

[sillysloft]

in which revision of fluxbox does this happen?

Original comment by: akir

[sillysloft]

commit bdfaaa0e173ad63e64c1166c0b524e1639ced12f Author: Petr Vorel petr.vorel@gmail.com Date: Fri Feb 24 13:09:58 2017 +0100

Original comment by: ge0rg

[sillysloft]

ah, sorry … those who are able to read "1.3.7 as well as latest git master". ok, i'll see what can be done. having a textWidth() resulting in 0 is really really strange. the crash following textWidth() == 0 comes naturally. but why the font renders "WW" as something which is 0 pixels wide ... maybe the font does not contain the proper glyphs. mhh.

Original comment by: akir

[sillysloft]

Maybe a bad combination of old (Debian SID) font libraries and a new font? Maybe something wrong in my font config? For reference, here the fonts.conf file in full:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

<fontconfig>
    <!--
  Make Emoji One Color the initial fallback font for sans-serif, sans, and monospace.
  -->
  <match>
      <test name="family"><string>sans-serif</string></test>
      <edit name="family" mode="prepend" binding="strong">
          <string>Emoji One Color</string>
      </edit>
  </match>
  <match>
      <test name="family"><string>serif</string></test>
      <edit name="family" mode="prepend" binding="strong">
          <string>Emoji One Color</string>
      </edit>
  </match>
  <match>
      <test name="family"><string>monospace</string></test>
      <edit name="family" mode="prepend" binding="strong">
          <string>Emoji One Color</string>
      </edit>
  </match>
  <match>
      <test name="family"><string>Apple Color Emoji</string></test>
      <edit name="family" mode="prepend" binding="strong">
          <string>Emoji One Color</string>
      </edit>
  </match>
  </fontconfig>

Original comment by: ge0rg

[sillysloft]

yah, it might be a bad config. but that does not solve the problem: we use "WW" as a "pretty wide character" to find out how many pixels a given font might consume or rather, how many glyphs might fit into the 0x8000 pixels (0x8000 is the max-width of x11 - because of "short") ... anyway, if "WW" is something "small" in some fonts, it's a bad signal anyway. i wonder, which other "sample" text we could use to detect the max-length...

Original comment by: akir

[sillysloft]

Leaving aside that the division should be guarded, the sublying problem will not resolve w/o handling fallback fonts. The Emoji thing really has no glyphs on the ASCII codepoints (and is thus btw. hardly usable for fluxbox cases anyway?)

See https://sourceforge.net/p/fluxbox/feature-requests/210/ https://sourceforge.net/p/fluxbox/bugs/1066/

Original comment by: baghira-style