GNU bug report logs - #63589
29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63589 <at> debbugs.gnu.org, tmdmelo <at> gmail.com
Subject: bug#63589: [PATCH] 29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb
Date: Tue, 23 May 2023 17:20:48 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: tmdmelo <at> gmail.com,  63589 <at> debbugs.gnu.org
> Date: Tue, 23 May 2023 21:18:04 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Then I don't understand your objections to the proposed patch.  Please
> > elaborate.
> 
> Please see the other thread(s), where I explained in detail the two
> problems with `gtk_init_check': upon success, it leaves two display
> connections open, which is quite fragile, and upon failure, it makes
> creating another display impossible, even if a display then becomes
> available.

I've read all those discussions in real time, and I still don't see
the obvious connection.  So please humor me with a more detailed and
complete explanation of why the last suggested patch somehow causes
extra connections open.  And let me remind you that your objection,
which is what caused my question, was

> We want closing displays (think x-delete-terminal) to still work on such
> builds if the user uses it.

Which seems to be about _closing_ connections, not about opening too
many of them.  It's the leap between the extra connections on the one
hand and closing display not working OTOH that I cannot make.  Please
help me fill the dots.

TIA

Previous Next

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