GNU bug report logs - #15037
Display can't be opened (display newer than emacs session)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15037 in the body.
You can then email your comments to 15037 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Sewall, Jason" <jason.sewall <at> intel.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Display can't be opened (display newer than emacs session) 
Date: Tue, 6 Aug 2013 20:52:07 +0000

I have a long-running emacs session with a server running on it (24.2.1, on Fedora 18). I have started up a new VNC session on the host, creating DISPLAY :1.0, but emacs refuses to let me create a frame on it: 

M-x make-frame-on-display <RET> :1.0 <RET>
Display :1.0 can't be opened

If I start a new emacs session with emacs (with -Q or not) and run the above, the frame is created.

I am not an expert in emacs frame handling nor in X, but it seems like emacs is reading the available displays when it starts up and refuses to connect to anything that started up after it. I'm happy to provide more info as needed. 

Cheers,
Jason

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

From: Glenn Morris <rgm <at> gnu.org>
To: "Sewall\, Jason" <jason.sewall <at> intel.com>
Cc: 15037 <at> debbugs.gnu.org
Subject: Re: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Tue, 06 Aug 2013 20:03:22 -0400

"Sewall, Jason" wrote:

> I have a long-running emacs session with a server running on it
> (24.2.1, on Fedora 18). I have started up a new VNC session on the
> host, creating DISPLAY :1.0, but emacs refuses to let me create a
> frame on it:
>
> M-x make-frame-on-display <RET> :1.0 <RET>
> Display :1.0 can't be opened
>
> If I start a new emacs session with emacs (with -Q or not) and run the
> above, the frame is created.
>
> I am not an expert in emacs frame handling nor in X, but it seems like
> emacs is reading the available displays when it starts up and refuses
> to connect to anything that started up after it.

With Emacs 24.2, the following works fine for me:

## Without X running
emacs -Q --daemon
startx &
## Back in the tty
emacsclient -t
## In Emacs
(make-frame-on-display ":0.0")

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: "Sewall, Jason" <jason.sewall <at> intel.com>
Cc: 15037 <at> debbugs.gnu.org
Subject: Re: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Wed, 7 Aug 2013 10:32:47 +0200

Hello.

6 aug 2013 kl. 22:52 skrev "Sewall, Jason" <jason.sewall <at> intel.com>:

> I have a long-running emacs session with a server running on it (24.2.1, on Fedora 18). I have started up a new VNC session on the host, creating DISPLAY :1.0, but emacs refuses to let me create a frame on it: 
> 
> M-x make-frame-on-display <RET> :1.0 <RET>
> Display :1.0 can't be opened
> 
> If I start a new emacs session with emacs (with -Q or not) and run the above, the frame is created.
> 
> I am not an expert in emacs frame handling nor in X, but it seems like emacs is reading the available displays when it starts up and refuses to connect to anything that started up after it. I'm happy to provide more info as needed. 

That is not what Emacs does.  "Reading available displays" is not possible.  Emacs just tries to connect when you do open display.
Did you kill the old server and start a new server in the same shell as you started the first?  My guess is that you did not, and so the second server either gets the correct authentication and thus can connect.

To really see what is going on you would need to debug Emacs with gdb when the make-frame-on-display fails.

	Jan D.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Sewall\, Jason" <jason.sewall <at> intel.com>
Cc: 15037 <at> debbugs.gnu.org
Subject: Re: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Wed, 07 Aug 2013 10:30:15 -0400

> M-x make-frame-on-display <RET> :1.0 <RET>
> Display :1.0 can't be opened

> If I start a new emacs session with emacs (with -Q or not) and run the
> above, the frame is created.

What does M-: (getenv "XAUTHORITY") RET say in those two Emacs sessions?


        Stefan

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

From: "Sewall, Jason" <jason.sewall <at> intel.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>,
 "15037 <at> debbugs.gnu.org" <15037 <at> debbugs.gnu.org>
Subject: RE: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Wed, 7 Aug 2013 17:31:18 +0000

> From: Stefan Monnier [mailto:monnier <at> iro.umontreal.ca]
> Sent: Wednesday, August 7, 2013 7:30 AM

> What does M-: (getenv "XAUTHORITY") RET say in those two Emacs sessions?

For the older session (in the original frame): "/var/run/gdm/auth-for-jsewall-jWCxJH/database"

For a new session started from display :1.0, 'nil'. 

Cheers,
Jason

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

From: "Sewall, Jason" <jason.sewall <at> intel.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>,
 "15037 <at> debbugs.gnu.org" <15037 <at> debbugs.gnu.org>
Subject: RE: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Wed, 7 Aug 2013 17:37:34 +0000

> From: Jan Djärv [mailto:jan.h.d <at> swipnet.se]
> Sent: Wednesday, August 7, 2013 1:33 AM

> That is not what Emacs does.  "Reading available displays" is not possible.
> Emacs just tries to connect when you do open display.

Makes sense. 

> Did you kill the old server and start a new server in the same shell as you
> started the first?  My guess is that you did not, and so the second server
> either gets the correct authentication and thus can connect.

If you mean kill emacs and restart it, I could certainly do that (it will work, from past experience) but it defeats the purpose from my point of view. I'd like emacs to be able to create a frame on any display I ask it to, no matter the relative age of the emacs session and the remote display. If you mean (server-start), that is easy to do, but my understanding is that it has nothing to do with remote displays. Indeed, if I do emacs -Q (i.e., starting no servers) I am able to do that make-frame-on-display without trouble (for an emacs newer than the display)

> To really see what is going on you would need to debug Emacs with gdb
> when the make-frame-on-display fails.

While that is fine, as a somewhat experienced programmer and noob with Emacs internals, I am very surprised there isn't a higher-level way to debug this sort of problem in emacs-lisp. It isn't something I have the time to figure up right now at any rate.

Cheers,
Jason

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

From: "Sewall, Jason" <jason.sewall <at> intel.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: "15037 <at> debbugs.gnu.org" <15037 <at> debbugs.gnu.org>
Subject: RE: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Wed, 7 Aug 2013 17:39:41 +0000

> From: Glenn Morris [mailto:rgm <at> gnu.org]
> Sent: Tuesday, August 6, 2013 5:03 PM
> With Emacs 24.2, the following works fine for me:
> 
> ## Without X running
> emacs -Q --daemon
> startx &
> ## Back in the tty
> emacsclient -t
> ## In Emacs
> (make-frame-on-display ":0.0")

That's good, but I suspect those conditions are different than the ones I am in. In particular, I am using GDM (and I haven't had to do startx manually for 10 years, I'd guess).

Cheers,
Jason

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Sewall\, Jason" <jason.sewall <at> intel.com>
Cc: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>,
 "15037 <at> debbugs.gnu.org" <15037 <at> debbugs.gnu.org>
Subject: Re: bug#15037: Display can't be opened (display newer than emacs
 session)
Date: Wed, 07 Aug 2013 14:19:59 -0400

>> What does M-: (getenv "XAUTHORITY") RET say in those two Emacs sessions?

> For the older session (in the original frame): "/var/run/gdm/auth-for-jsewall-jWCxJH/database"

> For a new session started from display :1.0, 'nil'. 

There's your problem.  You're using GDM3 which has the obnoxious habit
of putting your authorization keys in a separate file and setting
XAUTHORITY to point to it.  So your session doesn't have access to the
keys you have in your ~/.Xauthority and your other sessions don't have access
to this display.

See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586685
https://bugzilla.gnome.org/show_bug.cgi?id=651431

Note that it's not just Emacs that suffers this way:
If M-x make-frame-on-display <RET> :1.0 <RET> fails for you, then try
(in that very same Emacs) to do M-x shell RET xterm --display :1.0 RET
it should fail in the same way.


        Stefan

Previous Next

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