Discussion:
[dev] [dwm] Crash when setting window title to a single emoji
Markus Unterwaditzer
2016-08-29 17:56:56 UTC
Permalink
Hello,


I'm getting crashes with a particular emoji in the window title. Enter the
following in st/termite/xterm/urxvt (without tmux inbetween):

PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'

dwm's output:

dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331

System info:

- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).

- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.

Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.

This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.

Thanks,
Markus
Martin Kühne
2016-08-29 18:11:24 UTC
Permalink
On Mon, Aug 29, 2016 at 7:56 PM, Markus Unterwaditzer
Post by Markus Unterwaditzer
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
Urm, this page works very well for me on arch+dwm.

· Do you have an explicit UTF-8 locale and generated it as per wiki
instructions?
· Do you have patches applied?
· What font is your config.h set to?

cheers!
mar77i
FRIGN
2016-08-29 18:30:16 UTC
Permalink
On Mon, 29 Aug 2016 19:56:56 +0200
Markus Unterwaditzer <***@unterwaditzer.net> wrote:

Hey Markus,
Post by Markus Unterwaditzer
I'm getting crashes with a particular emoji in the window title.
Enter the following in st/termite/xterm/urxvt (without tmux
[...]
This is my first attempt at debugging anything Xorg-related, not sure
what else could be important.
I can not reproduce it here.

Cheers

FRIGN
--
FRIGN <***@frign.de>
Markus Unterwaditzer
2016-08-29 18:31:19 UTC
Permalink
Post by Markus Unterwaditzer
Hello,
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).
- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.
Thanks,
Markus
I forgot to mention, the reason I believe this is a DWM issue rather than an
Xorg one is because I don't experience such crashes with e.g. Openbox as window
manager.

-- Markus
Markus Unterwaditzer
2016-08-29 19:01:46 UTC
Permalink
Hello Martin,

I'm replying to you this way because I've subscribed without recieving emails
(dev+subscribe-nomail). I assumed people would auto-CC me on replies. Anyway,
I'm now fully subscribed.
Do you have an explicit UTF-8 locale and generated it as per wiki instructions?
I'm assuming you mean the Arch Wiki. I have `LANG=en_US.UTF-8` in my
locale.conf, uncommented the relevant parts in /etc/locale.gen and of course
generated the locale file. I don't have any `LC_*` variables set, even though I
don't believe that those are necessary, I did try setting `LC_ALL=en_US.UTF-8`
as well.

$ locale -a
C
en_US
en_US.iso88591
en_US.utf8
POSIX

$ localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: de-latin1
X11 Layout: n/a

I also don't have any issues with other unicode symbols (including emojis) in
any other program. Only this one in particular doesn't work.
Urm, this page works very well for me on arch+dwm.
The page itself is not the problem, the window title is. Does your browser set
its window title to contain the page title?
Do you have patches applied?
I've tried with and without patches.
What font is your config.h set to?
I've already elaborated that in the OP, I have tried Terminus, Source Code Pro
and Droid Sans.

-- Markus
Greg Reagle
2016-08-29 18:34:40 UTC
Permalink
I cannot reproduce it on my computer.  Using
Debian 8.5,
dwm commit 7af4d439bdb5a2e40aca69446a3367bd71431c45 (which is behind the
latest),
xserver-xorg                  1:7.7+7
Markus Unterwaditzer
2016-08-29 19:12:19 UTC
Permalink
Post by Markus Unterwaditzer
Hello,
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).
- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.
Thanks,
Markus
Since nobody can reproduce it, apparently you have to install the bdf-unifont
from `extras`.

My journey continues...
Martin Kühne
2016-08-29 19:21:08 UTC
Permalink
On Mon, Aug 29, 2016 at 9:12 PM, Markus Unterwaditzer
Post by Markus Unterwaditzer
Since nobody can reproduce it, apparently you have to install the bdf-unifont
from `extras`.
My journey continues...
No, I'm too lazy to crash my stuff tonight. Btw, the website lists
version 9.0.02 as the current version, arch offers version 8.0.01. Can
you try to bump the version manually?

cheers!
mar77i


On Mon, Aug 29, 2016 at 9:12 PM, Markus Unterwaditzer
Post by Markus Unterwaditzer
Post by Markus Unterwaditzer
Hello,
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).
- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.
Thanks,
Markus
Since nobody can reproduce it, apparently you have to install the bdf-unifont
from `extras`.
My journey continues...
Markus Unterwaditzer
2016-08-29 19:35:39 UTC
Permalink
Post by Martin Kühne
On Mon, Aug 29, 2016 at 9:12 PM, Markus Unterwaditzer
Post by Markus Unterwaditzer
Since nobody can reproduce it, apparently you have to install the bdf-unifont
from `extras`.
My journey continues...
No, I'm too lazy to crash my stuff tonight.
That's fair enough, I'm not particularly keen on it either :)

Note that after installing bdf-unifont on another machine, I couldn't fix this
issue by uninstalling the package. But at least I've been able to reproduce it,
yay? The package does seem to have proper hooks that invoke fc-cache.
Post by Martin Kühne
Btw, the website lists version 9.0.02 as the current version, arch offers
version 8.0.01. Can you try to bump the version manually?
Yeah, I'll try that. Thanks!
Post by Martin Kühne
cheers!
mar77i
On Mon, Aug 29, 2016 at 9:12 PM, Markus Unterwaditzer
Post by Markus Unterwaditzer
Post by Markus Unterwaditzer
Hello,
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).
- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.
Thanks,
Markus
Since nobody can reproduce it, apparently you have to install the bdf-unifont
from `extras`.
My journey continues...
Markus Unterwaditzer
2016-08-29 20:01:28 UTC
Permalink
Post by Markus Unterwaditzer
[...]
Post by Martin Kühne
[...]
Btw, the website lists version 9.0.02 as the current version, arch offers
version 8.0.01. Can you try to bump the version manually?
Yeah, I'll try that. Thanks!
No luck with that version either. I've tried running `fc-cache -r` too.

-- Markus
Post by Markus Unterwaditzer
Post by Martin Kühne
cheers!
mar77i
On Mon, Aug 29, 2016 at 9:12 PM, Markus Unterwaditzer
Post by Markus Unterwaditzer
Post by Markus Unterwaditzer
Hello,
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).
- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.
Thanks,
Markus
Since nobody can reproduce it, apparently you have to install the bdf-unifont
from `extras`.
My journey continues...
Anselm R Garbe
2016-08-30 06:28:21 UTC
Permalink
On 29 August 2016 at 19:56, Markus Unterwaditzer
Post by Markus Unterwaditzer
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
I wonder if this is a crash at all. It rather looks like a fatal Xlib
error to me.

Do you get coredumps of dwm? If yes, please provide a stack trace.

BR,
Anselm
Markus Unterwaditzer
2016-08-30 11:18:22 UTC
Permalink
Hello Anselm,
Post by Anselm R Garbe
[...]
I wonder if this is a crash at all. It rather looks like a fatal Xlib
error to me.
I'm not sure how that doesn't qualify as crash. What is your definition of
crash?
Post by Anselm R Garbe
Do you get coredumps of dwm? If yes, please provide a stack trace.
None.

-- Markus
Post by Anselm R Garbe
BR,
Anselm
Paul Menzel
2016-08-30 11:30:20 UTC
Permalink
Dear Markus,
[…]
Post by Anselm R Garbe
Do you get coredumps of dwm? If yes, please provide a stack trace.
None.
How do you start dwm?


Best regards,

Paul
Markus Unterwaditzer
2016-08-30 17:32:13 UTC
Permalink
Hello Paul,
Post by Paul Menzel
None.
How do you start dwm?
A simple `dwm` in `.xinitrc`. You can view the entire setup here:
https://github.com/untitaker/dotfiles

-- Markus
Post by Paul Menzel
Best regards,
Paul
Paul Menzel
2016-08-31 13:52:36 UTC
Permalink
Dear Markus,
Post by Markus Unterwaditzer
Post by Paul Menzel
None.
How do you start dwm?
https://github.com/untitaker/dotfiles
Did you already try running dwm under GDB? You could add it to the
`.xinitrc` file and attach to GDB remotely I guess.


Liebe Grüße

Paul
Markus Unterwaditzer
2016-08-31 19:07:21 UTC
Permalink
Post by Paul Menzel
Dear Markus,
Post by Markus Unterwaditzer
Post by Paul Menzel
None.
How do you start dwm?
https://github.com/untitaker/dotfiles
Did you already try running dwm under GDB? You could add it to the
`.xinitrc` file and attach to GDB remotely I guess.
Liebe Grüße
Paul
Hello Paul,

Well, I have tried now! Attached is the entire session.

I'm not sure what to look for. In another session I noticed that shortly before
`drw_text` gets called `text` being a nullpointer. It appears that the code is
designed to deal with this though.

By the way, this time I reproduced this issue using:

echo -e "\xe2\x9b\x93b" | xargs xsetroot -name

Thanks for your help,
Markus
Markus Unterwaditzer
2016-08-31 19:22:44 UTC
Permalink
Post by Markus Unterwaditzer
Post by Paul Menzel
Dear Markus,
Post by Markus Unterwaditzer
Post by Paul Menzel
None.
How do you start dwm?
https://github.com/untitaker/dotfiles
Did you already try running dwm under GDB? You could add it to the
`.xinitrc` file and attach to GDB remotely I guess.
Liebe Grüße
Paul
Hello Paul,
Well, I have tried now! Attached is the entire session.
I'm not sure what to look for. In another session I noticed that shortly before
`drw_text` gets called `text` being a nullpointer. It appears that the code is
designed to deal with this though.
echo -e "\xe2\x9b\x93b" | xargs xsetroot -name
Thanks for your help,
Markus
Sorry, forgot the actual attachment. Here it is.
Paul Menzel
2016-09-05 09:10:53 UTC
Permalink
Dear Markus,
Post by Markus Unterwaditzer
Post by Markus Unterwaditzer
Post by Paul Menzel
Post by Markus Unterwaditzer
Post by Paul Menzel
None.
How do you start dwm?
https://github.com/untitaker/dotfiles
Did you already try running dwm under GDB? You could add it to the
`.xinitrc` file and attach to GDB remotely I guess.
Well, I have tried now! Attached is the entire session.
I'm not sure what to look for. In another session I noticed that shortly before
`drw_text` gets called `text` being a nullpointer. It appears that the code is
designed to deal with this though.
echo -e "\xe2\x9b\x93b" | xargs xsetroot -name
Thanks for your help,
Markus
Sorry, forgot the actual attachment. Here it is.
No problem. Thank you very much for that. Unfortunately, I won’t have
time until the end of the week to look more into it.

If you have time until then, could you please also run the process under
Valgrind, or build the stack with some sanitizers (address, undefined
behavior)?

```
$ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind \
-v \
--tool=memcheck \
--leak-check=full \
--num-callers=40 \
--log-file=valgrind.log \
$(which <program>) <arguments>
```


Best regards,

Paul


PS: By the way, you should be able to attach to running processes too.


[1] https://wiki.ubuntu.com/Valgrind
Markus Unterwaditzer
2016-09-05 15:29:17 UTC
Permalink
Post by Paul Menzel
Dear Markus,
Post by Markus Unterwaditzer
Post by Markus Unterwaditzer
Post by Paul Menzel
Post by Markus Unterwaditzer
Post by Paul Menzel
None.
How do you start dwm?
https://github.com/untitaker/dotfiles
Did you already try running dwm under GDB? You could add it to the
`.xinitrc` file and attach to GDB remotely I guess.
Well, I have tried now! Attached is the entire session.
I'm not sure what to look for. In another session I noticed that shortly before
`drw_text` gets called `text` being a nullpointer. It appears that the code is
designed to deal with this though.
echo -e "\xe2\x9b\x93b" | xargs xsetroot -name
Thanks for your help,
Markus
Sorry, forgot the actual attachment. Here it is.
No problem. Thank you very much for that. Unfortunately, I won’t have time
until the end of the week to look more into it.
If you have time until then, could you please also run the process under
Valgrind, or build the stack with some sanitizers (address, undefined
behavior)?
```
$ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind \
-v \
--tool=memcheck \
--leak-check=full \
--num-callers=40 \
--log-file=valgrind.log \
$(which <program>) <arguments>
```
Best regards,
Paul
PS: By the way, you should be able to attach to running processes too.
[1] https://wiki.ubuntu.com/Valgrind
Hello Paul,

Attached is the valgrind.log.

Thanks for your help,
Markus

Anselm R Garbe
2016-08-30 11:35:12 UTC
Permalink
This post might be inappropriate. Click to display it.
Markus Unterwaditzer
2016-08-30 17:35:28 UTC
Permalink
Hello Anselm,
Post by Anselm R Garbe
To me a crash is an illegal control flow of a program that is detected
and aborted by the governing system (libc, etc.).
In contrast an exit() caused by the Xlib error handler is kind of a
legal control flow to me, though from a user perspective similar.
I see. To me a crash is any failing program invocation that is not caused by
invalid user input. IMO a malformed environment doesn't count as user input
(with some exceptions).
Post by Anselm R Garbe
BR,
Anselm
Markus Unterwaditzer
2016-08-31 13:29:25 UTC
Permalink
Post by Markus Unterwaditzer
Hello,
I'm getting crashes with a particular emoji in the window title. Enter the
PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
dwm: fatal error: request code=140, error code=16
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 140 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 4319
Current serial number in output stream: 4331
- I'm using dwm from commit 14343e6, but can reproduce with latest master as
well. The configuration doesn't seem to matter at all. I can reproduce this
with any font for the titlebar (I've tried Droid Sans, Terminus, Source Code
Pro).
- My operating system is ArchLinux, the xorg-server package is at 1.15.2-1. But
again, this has been happening for quite a while now, there have been a few
Xorg upgrades inbetween.
Originally I've experienced this issue when opening the following URL in
Firefox or Chromium: https://github.com/RustFestEU/conf-2016/issues/2 That page
has a <title> tag with that emoji, which then lands in the window title as
well.
This is my first attempt at debugging anything Xorg-related, not sure what else
could be important.
Thanks,
Markus
Here's another one that fails:

PROMPT_COMMAND='echo -ne "\x1b]0;\xf0\x9f\xa4\x94\x07"'

taken from:

https://twitter.com/djm_/status/770938881206317056

I seriously do wonder if anybody can reproduce this. I can on two machines, one
of them didn't have this problem until I installed bdf-unifont (either 9.0.02
or 0.0.01)

Thanks,
Markus
FRIGN
2016-08-31 13:36:10 UTC
Permalink
On Wed, 31 Aug 2016 15:29:25 +0200
Markus Unterwaditzer <***@unterwaditzer.net> wrote:

Hey Markus,
Post by Markus Unterwaditzer
PROMPT_COMMAND='echo -ne "\x1b]0;\xf0\x9f\xa4\x94\x07"'
https://twitter.com/djm_/status/770938881206317056
I seriously do wonder if anybody can reproduce this. I can on two
machines, one of them didn't have this problem until I installed
bdf-unifont (either 9.0.02 or 0.0.01)
your dotfiles repo shows me that your setup really is anything but
transparent. Your .xinitrc is a mess and stages an environment before
starting dwm.
Try to set up a minimal working example in a clean environment, e.g.
try running gentoo and write the .xinitrc yourself. Your lack of
control over this environment will forever hinder us from finding the
cause of this issue.

Cheers

FRIGN
--
FRIGN <***@frign.de>
Markus Unterwaditzer
2016-08-31 18:54:20 UTC
Permalink
Post by FRIGN
On Wed, 31 Aug 2016 15:29:25 +0200
Hey Markus,
Post by Markus Unterwaditzer
PROMPT_COMMAND='echo -ne "\x1b]0;\xf0\x9f\xa4\x94\x07"'
https://twitter.com/djm_/status/770938881206317056
I seriously do wonder if anybody can reproduce this. I can on two
machines, one of them didn't have this problem until I installed
bdf-unifont (either 9.0.02 or 0.0.01)
your dotfiles repo shows me that your setup really is anything but
transparent. Your .xinitrc is a mess and stages an environment before
starting dwm.
Try to set up a minimal working example in a clean environment, e.g.
try running gentoo and write the .xinitrc yourself. Your lack of
control over this environment will forever hinder us from finding the
cause of this issue.
Cheers
FRIGN
--
FRIGN,

I can reproduce this with a barebones dwm installation on a fresh ArchLinux
installation.

Did you try the reproduction steps I gave in the OP (including installing
bdf-unifont)?

-- Markus
Greg Reagle
2016-08-31 14:30:58 UTC
Permalink
    PROMPT_COMMAND='echo -ne "\x1b]0;\xf0\x9f\xa4\x94\x07"'
Well it shows up for me as a sort of inverse (foreground and background
switched) question mark, but no malfunction, and this is from config.h
of my dwm:

static const char *fonts[]          = { "monospace:size=10" };
static const char dmenufont[]       = "monospace:size=10";

which apparently maps to DejaVu:
***@t400 ~/s/p/lua> fc-match 'monospace:size=10'
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
Markus Unterwaditzer
2016-08-31 17:05:55 UTC
Permalink
Post by Greg Reagle
    PROMPT_COMMAND='echo -ne "\x1b]0;\xf0\x9f\xa4\x94\x07"'
Well it shows up for me as a sort of inverse (foreground and background
switched) question mark, but no malfunction, and this is from config.h
static const char *fonts[]          = { "monospace:size=10" };
static const char dmenufont[]       = "monospace:size=10";
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
Greg, the issue only appears to me if I install bdf-unifont from [extras]. I
could reproduce it on another machine with a different environment and a
vanilla dwm installation simply by installing that package. Uninstalling it
didn't cause the issue to go away again.
Greg Reagle
2016-08-31 17:35:30 UTC
Permalink
Post by Markus Unterwaditzer
Greg, the issue only appears to me if I install bdf-unifont from
[extras].
Okay. I don't have that package available on Debian 8.5. Would any of
these be appropriate?
***@t400 ~> acseno bdf
bdfresize - tool for resizing BDF format font
bdf2psf - font converter to generate console fonts from BDF source fonts
libghc-shakespeare-dev - toolkit for making compile-time interpolated
templates
libghc-shakespeare-prof - toolkit for making compile-time interpolated
templates; profiling libraries
otf2bdf - generate BDF bitmap fonts from OpenType outline fonts
pcf2bdf - convert X11 font from PCF to BDF format
***@t400 ~> acseno unifont
psf-unifont - PSF (console) version of GNU Unifont with APL support
ttf-unifont - TrueType version of GNU Unifont
unifont - font with a glyph for each visible Unicode Plane 0 character
unifont-bin - utilities for manipulating GNU Unifont
xfonts-unifont - PCF (bitmap) version of GNU Unifont
Markus Unterwaditzer
2016-08-31 18:59:05 UTC
Permalink
Post by Greg Reagle
Post by Markus Unterwaditzer
Greg, the issue only appears to me if I install bdf-unifont from
[extras].
Okay. I don't have that package available on Debian 8.5. Would any of
these be appropriate?
bdfresize - tool for resizing BDF format font
bdf2psf - font converter to generate console fonts from BDF source fonts
libghc-shakespeare-dev - toolkit for making compile-time interpolated
templates
libghc-shakespeare-prof - toolkit for making compile-time interpolated
templates; profiling libraries
otf2bdf - generate BDF bitmap fonts from OpenType outline fonts
pcf2bdf - convert X11 font from PCF to BDF format
psf-unifont - PSF (console) version of GNU Unifont with APL support
ttf-unifont - TrueType version of GNU Unifont
unifont - font with a glyph for each visible Unicode Plane 0 character
unifont-bin - utilities for manipulating GNU Unifont
xfonts-unifont - PCF (bitmap) version of GNU Unifont
Hello Greg,

I think the `unifont` package is it. For comparison, this is the content of the
bdf-unifont package on ArchLinux:

/usr/
/usr/share/
/usr/share/fonts/
/usr/share/fonts/misc/
/usr/share/fonts/misc/unifont.bdf
/usr/share/licenses/
/usr/share/licenses/bdf-unifont/
/usr/share/licenses/bdf-unifont/LICENSE

-- Markus
Greg Reagle
2016-08-31 23:32:25 UTC
Permalink
Post by Markus Unterwaditzer
Hello Greg,
I think the `unifont` package is it. For comparison, this is the content of the
/usr/
/usr/share/
/usr/share/fonts/
/usr/share/fonts/misc/
/usr/share/fonts/misc/unifont.bdf
/usr/share/licenses/
/usr/share/licenses/bdf-unifont/
/usr/share/licenses/bdf-unifont/LICENSE
A bdf version of unifont does not seem to be available in the regular
packages on my system (Debian 8.5). I do get unifont.pcf.gz and
unifont.ttf though. Anyway, I still couldn't reproduce the bug with
the following in config.h of my dwm:

static const char *fonts[] = { "Unifont" };
Loading...