On Thu, Jan 10, 2019 at 04:36:25AM +0000, Jakub Labath wrote:
> Hi
>
> So I experienced this problems myself , this was roughly my journey.
>
> I messed with fonts on my gentoo installing some from google some time
> after X would start crashing when surfing web.
> Eventually got lucky and found this website
> https://github.com/dylanaraps/neofetch that reproduces the crash
> reliably.
> (Culprit is the https://www.compart.com/en/unicode/U+1F5BC)
>
> Eventually traced the crash to
>
>
> dwm: fatal error: request code=138, error code=16
> X Error of failed request: BadLength (poly request too large or
> internal Xlib length error)
> Major opcode of failed request: 138 (RENDER)
> Minor opcode of failed request: 20 (RenderAddGlyphs)
> Serial number of failed request: 1858
> Current serial number in output stream: 1869
> xinit: connection to X server lost
>
> which brought me here.
>
> I tried the patch from Igor but while it prevented the crash it left
> my dwm unusable.
> Wrote my own hack that removes non-ascii characters from the text
> written on the title bar (or any dwm text) and I am happy since.
>
> I am attaching my hack for reference but I do not think it's patch
> worthy as it removes the ability to have any national characters.
>
> Maybe I am an edge case but I was shocked to see dwm crashing given
> that it was otherwise rock solid for a decade+.
> I understand that the problem may lie with Xft and maybe that is what
> needs to be fixed, but it still kind of makes dwm look bad.
>
> I mean failure to render a glyph should never take down the Xorg - can
> anyone think of a more intelligent way to defend against this?
>
> My OS is gentoo - latest dwm and my Xorg and Xft are the latest in gentoo
>
> x11-libs/libXft 2.3.2-r1
> x11-base/xorg-server 1.20.3
> media-fonts/noto 20170403 (google fonts)
>
> Cheers
>
> Jakub
> diff --git a/dwm.c b/dwm.c
> index 4465af1..dd9bbe2 100644
> --- a/dwm.c
> +++ b/dwm.c
> _AT_@ -899,23 +899,40 @@ getstate(Window w)
> return result;
> }
>
> +void
> +sub_non_ascii_chars(char *txt, unsigned int size) {
> + int i;
> + for (i = 0; i < size; i++){
> + //fprintf(stderr, "%c at idx %d is %d\n", txt[i], i, txt[i]);
> + if (txt[i] > 127 || txt[i] < 0) {
> + txt[i] = '?';
> + }
> + }
> + //fprintf(stderr, "OUT |%s|\n", txt);
> +}
> +
> int
> gettextprop(Window w, Atom atom, char *text, unsigned int size)
> {
> char **list = NULL;
> int n;
> XTextProperty name;
> + char buf[size-1];
>
> if (!text || size == 0)
> return 0;
> text[0] = '\0';
> if (!XGetTextProperty(dpy, w, &name, atom) || !name.nitems)
> return 0;
> - if (name.encoding == XA_STRING)
> - strncpy(text, (char *)name.value, size - 1);
> - else {
> + if (name.encoding == XA_STRING) {
> + strncpy(buf, (char *)name.value, size - 1);
> + sub_non_ascii_chars(buf, size-1);
> + strncpy(text, buf, size - 1);
> + } else {
> if (XmbTextPropertyToTextList(dpy, &name, &list, &n) >= Success && n > 0 && *list) {
> - strncpy(text, *list, size - 1);
> + strncpy(buf, *list, size - 1);
> + sub_non_ascii_chars(buf, size -1);
> + strncpy(text, buf, size - 1);
> XFreeStringList(list);
> }
> }
>
Hi Jakub,
It is a known issue (Google Noto fonts with color emojis) crashing Xft
applications. Not only dwm is affected.
The previous proposed fixes in this thread ignore the underlying errors, which
is bad. I like your workaround more, but it is still not a solution.
Xft needs to fix this known bug and/or we need to switch from Xft. The only
one looking bad is Xft here (and having color emojis in fonts).
--
Kind regards,
Hiltjo
Received on Thu Jan 10 2019 - 09:58:13 CET