GNU bug report logs - #17975
24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Previous Next

Full log

View this message in rfc822 format

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17975 <at> debbugs.gnu.org
Subject: bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)
Date: Fri, 11 Jul 2014 17:22:17 -0400

Dmitry Antipov <dmantipov <at> yandex.ru> writes:
> Reproduced. The whole thing looks like a mystery (perhaps Xlib makes a
> difference between :0 and :0.0 somewhere in its innards), but this
> workaround works for me. Can you please try it too?

It works for me too. Of course, my saved .emacs.desktop already has a
mix of display names in it; I'll have to get them in sync.

But of course it isn't going to address some reasonable uses of
make-frame-on-display (including perhaps old scripts some of us may have
lying around that invoke make-frame-on-display by way of emacsclient
--eval). Perhaps a similar change can be made within the main Emacs
code?

I can reformulate the recipe in a form without emacsclient, for testing
purposes:

 $ DISPLAY=:0 emacs -Q --eval \
 '(let ((f (selected-frame))) (make-frame-on-display ":0.0") (delete-frame f))'

If I use "(make-frame)" instead, or give make-frame-on-display the
initial DISPLAY value, it works fine.

It appears that mixing ":0" and "unix:0" can trigger the problem, too.
At least in my X11 environment, ":0" or ":0.0" seem to be the preferred
forms. So launching a non-daemon Emacs from xterm and then using the
modified emacsclient with it could also be a problem, but I haven't
tested it yet.

Ken

Previous Next

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