GNU bug report logs - #76944
31.0.50; X protocol error: BadGC (invalid GC parameter) on protocol request 60

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 76944 <at> debbugs.gnu.org
Subject: bug#76944: 31.0.50; X protocol error: BadGC (invalid GC parameter) on protocol request 60
Date: Thu, 13 Mar 2025 09:39:33 +0800

Visuwesh <visuweshm <at> gmail.com> writes:

> [புதன் மார்ச் 12, 2025] Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> You must also break on x_error_quitter.  That will reveal the true
>> source of the X error.
>
> Hmm, from what I understand, src/.gdbinit already sets a break point for
> this function.  I think the command line flag -xrm "emacs.synchronous:
> true" wasn't respected by the daemon which is why I couldn't get a
> proper backtrace out of the previous process?  I now did
>
>     M-: (x-synchronize t)
>
> in a frame, and it is noticeably slower to type.  However, it seems like
> I need to do this for every frame I open.
>
> How can I check if the xrm flag is respected?  Doing
>
>     M-: (x-get-resource "synchronous" "Synchronous")
>
> returns nil.

Judging by the backtrace and the deadlock in acquiring an internal Cairo
lock, some error was detected and prompted Emacs or another error
handler to longjmp with that lock held.  The state of XSynchronize is
not really material now--if a breakpoint was indeed placed on
x_error_quitter, perhaps you could attempt to break on
x_io_error_quitter or _XError this time.

Previous Next

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