GNU bug report logs - #73456
31.0.50; X protocol error: RenderBadGlyph

Previous Next

Full log

Message #8 received at 73456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>, Po Lu <luangruo <at> yahoo.com>
Cc: 73456 <at> debbugs.gnu.org
Subject: Re: bug#73456: 31.0.50; X protocol error: RenderBadGlyph
Date: Tue, 24 Sep 2024 21:07:03 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Tue, 24 Sep 2024 22:20:54 +0530
> 
> I am using Xfce4 4.18.  When trying to focus an emacsclient frame that
> was beneath Firefox, all open frames were suddenly killed.  Opening a
> new frame had the following in the *Messages* buffer:
> 
>     X protocol error: RenderBadGlyph (invalid Glyph parameter) on protocol request 139
>     Serial no: 29516839
>     Failing resource ID (if any): 0x21
>     Minor code: 22
>     This is a bug!  Please report this to bug-gnu-emacs <at> gnu.org!
> 
> This isn't the first time this has happened.  Something similar happened
> a couple of days back, and it killed Emacs with the following backtrace:
> 
>     Backtrace:
>     emacs(+0x199dfb)[0x55bc40b6edfb]
>     emacs(+0x4b22a)[0x55bc40a2022a]
>     emacs(+0x4b727)[0x55bc40a20727]
>     emacs(+0x4b72e)[0x55bc40a2072e]
>     emacs(+0x1983d9)[0x55bc40b6d3d9]
>     /lib/x86_64-linux-gnu/libc.so.6(+0x3f590)[0x7fda07ec1590]
>     /lib/x86_64-linux-gnu/libX11.so.6(+0x31f48)[0x7fda09829f48]
>     /lib/x86_64-linux-gnu/libX11.so.6(XEventsQueued+0x1b)[0x7fda0982dd5b]
>     /lib/x86_64-linux-gnu/libXt.so.6(XtAppPending+0x6d)[0x7fda099ab82d]
>     emacs(+0xc3205)[0x55bc40a98205]
>     emacs(+0xc32ce)[0x55bc40a982ce]
>     emacs(+0xc4b14)[0x55bc40a99b14]
>     emacs(+0xc21ea)[0x55bc40a971ea]
>     emacs(+0x252af9)[0x55bc40c27af9]
>     emacs(+0x20a7a6)[0x55bc40bdf7a6]
>     emacs(+0x20343e)[0x55bc40bd843e]
>     emacs(+0x20a7a6)[0x55bc40bdf7a6]
>     emacs(+0x204a62)[0x55bc40bd9a62]
>     emacs(+0x252af9)[0x55bc40c27af9]
>     emacs(+0x20a7a6)[0x55bc40bdf7a6]
>     emacs(+0x18c6b5)[0x55bc40b616b5]
>     emacs(+0x206017)[0x55bc40bdb017]
>     emacs(+0x177bbe)[0x55bc40b4cbbe]
>     emacs(+0x205f71)[0x55bc40bdaf71]
>     emacs(+0x177b53)[0x55bc40b4cb53]
>     emacs(+0x17f491)[0x55bc40b54491]
>     emacs(+0x17f820)[0x55bc40b54820]
>     emacs(+0x53caa)[0x55bc40a28caa]
>     /lib/x86_64-linux-gnu/libc.so.6(+0x29c8a)[0x7fda07eabc8a]
>     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7fda07eabd45]
>     emacs(+0x541c1)[0x55bc40a291c1]
> 
> This is probably not useful in any degree but I am including it in hopes
> that it might hint at something.  I tried running the debug build of
> Emacs in hopes of catching this backtrace for some time but it was
> unfruitful since this is only reproduced rarely.

Thanks, but the only way to debug these problems is to run Emacs under
GDB at all times, and run it in X-synchronous mode (as described in
etc/DEBUG).  Only then, when the rare problem happens, you will be
able to collect a meaningful backtrace which will point out the
offending code.

Unless Po Lu has a lucky guess, of course...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.