bug#20247: 24.4; Emacs hangs at startup in desktop mode

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Richard Munitz (BLOOMBERG/ 731 LEX)]

[-- Attachment #1: Type: text/plain, Size: 6188 bytes --]

--text follows this line--
I have emacs configured in my .emacs to save desktop settings:
(desktop-save-mode 1)
(setq desktop-auto-save-timeout 60)

I work on Solaris and access via xterm.  I also use tmux on top of that.   The machine is restarted periodically (always on the weekends for example) and I am forced to log back in.  After I do this, I often find that when I start emacs (just run "emacs"), it hangs and I have no choice but to kill it.  I have tried exiting emacs before leaving before work for the weekend and had this hang occur when I returned on Monday.

I have done some investigation and have determined that the hang is caused by the presence of something like the following string in my ~/.emacs.d/.emacs.desktop file: (display . "sundev28:37.0")
That display value winds up being the value that was in effect during my prior login.  However my new login/xterm is assigned a different display value.  I have determined that if I edit the desktop file (emacs .emacs.desktop file --no-desktop) and change that display string to the current $DISPLAY value, emacs now starts without hanging.

I find that the hang is not consistent.  For example, if I simply edit the display value to some bogus value (e.g. change the 37 above to 137), emacs at least comes up without hanging.  It doesn't restore my desktop layout (frame position, size, splits), and it instead displays the warning: 
Error (frameset): Display sundev28:137.0 can't be opened
Warning (frameset): Attempt to delete the sole visible or iconified frame

Some more information.  This problem could be related to tmux.  The last time the hang occurred I noticed that my environment settings had different values for XTERM and DISPLAY.  Currently they look like the below, but on that day they were different.  Unfortunately, I don't remember which was which.  But the .emacs.desktop file had one of the two values and it hung.  When I edited the file and changed it to the other of the two values, it started flawlessly.
XTERM=/usr/bin/X11/xterm -ls -sb -sl 4000 -display sundev28:37.0
DISPLAY=sundev28:37.0

Of course I don't understand the internals, but I don't understand why emacs starts up and tries to use a saved "display" value at all?  Why doesn't it just always use the display value defined in the current shell in which I am invoking emacs?  Perhaps this is sometimes desirable, but is there a setting I can use to make emacs ignore this value saved in the desktop file and always use the value from the current environment?


In GNU Emacs 24.4.1 (sparc-sun-solaris2.10, GTK+ Version 3.8.9)
of 2015-03-25 on njsbldo2
Windowing system distributor `Hummingbird - Open Text', version 11.0.13830
Configured using:
`configure --prefix=/opt/bb --libdir=/opt/bb/lib64
-x-includes=/opt/bb/include -x-libraries=/opt/bb/lib64
--without-selinux --with-png=no --with-gif=no --without-gsettings
CFLAGS=-m64 CPPFLAGS=-I/opt/bb/include 'LDFLAGS=-m64 -L/opt/bb/lib64
-R/opt/bb/lib64''

Important settings:
value of $LANG: C
locale-coding-system: nil

Major mode: Info

Minor modes in effect:
desktop-save-mode: t
electric-pair-mode: t
show-paren-mode: t
delete-selection-mode: t
global-linum-mode: t
linum-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
global-visual-line-mode: t
visual-line-mode: t
transient-mark-mode: t

Recent input:
C-x k <return> C-x C-b <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<emacs-manual-bug> <help-echo> <down-mouse-1> <mouse-1> 
<down-mouse-1> <mouse-1> <help-echo> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <down-mouse-1> <mouse-1> C-x 
2 M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Note: file is write protected
Using vacuous schema [3 times]
Wrote /home/rmunitz1/.emacs.d/.emacs.desktop.lock
Desktop: 1 frame, 15 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.
Updating buffer list...
Formats have changed, recompiling...done
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils jka-compr info cl-macs ibuf-ext ibuffer
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok
vc-git cc-langs cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs view thai-util thai-word
mule-util lao-util zenburn-theme highlight-symbol easy-mmode cl gv
thingatpt desktop frameset cl-loaddefs cl-lib elec-pair paren delsel ido
linum time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

Memory information:
((conses 16 284718 6555)
(symbols 48 35230 0)
(miscs 40 2895 633)
(strings 32 48468 7766)
(string-bytes 1 1308158)
(vectors 16 20642)
(vector-slots 8 690582 22734)
(floats 8 173 495)
(intervals 56 5319 732)
(buffers 960 28))


[-- Attachment #2: Type: text/html, Size: 7964 bytes --]

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Glenn Morris]

"Richard Munitz (BLOOMBERG/ 731 LEX)" wrote:

> Some more information. This problem could be related to tmux. The last
> time the hang occurred I noticed that my environment settings had
> different values for XTERM and DISPLAY. Currently they look like the
> below, but on that day they were different. Unfortunately, I don't
> remember which was which. But the .emacs.desktop file had one of the
> two values and it hung. When I edited the file and changed it to the
> other of the two values, it started flawlessly.
> XTERM=/usr/bin/X11/xterm -ls -sb -sl 4000 -display sundev28:37.0
> DISPLAY=sundev28:37.0
>
> Of course I don't understand the internals, but I don't understand why
> emacs starts up and tries to use a saved "display" value at all? Why
> doesn't it just always use the display value defined in the current
> shell in which I am invoking emacs? Perhaps this is sometimes
> desirable, but is there a setting I can use to make emacs ignore this
> value saved in the desktop file and always use the value from the
> current environment?


Maybe setting desktop-restore-in-current-display to t will help?

I suspect that in that variable's doc:

   If nil, restores frames into their original displays (if possible).

the "(if possible)" part is going to be tricky to get right.

See also http://debbugs.gnu.org/17693#40

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Richard Munitz (BLOOMBERG/ 731 LEX)]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Thanks.  On my first restart attempt, setting desktop-restore-in-current-display to t seems to have enabled me to restore as expected (unless by coincidence I was given the same display as the last time - I didn't check).

From: rgm@gnu.org At: Apr 15 2015 14:03:51
To: Richard Munitz (BLOOMBERG/ 731 LEX)
Cc: 20247@debbugs.gnu.org
Subject: Re: bug#20247: 24.4; Emacs hangs at startup in desktop mode

"Richard Munitz (BLOOMBERG/ 731 LEX)" wrote:

> Some more information. This problem could be related to tmux. The last
> time the hang occurred I noticed that my environment settings had
> different values for XTERM and DISPLAY. Currently they look like the
> below, but on that day they were different. Unfortunately, I don't
> remember which was which. But the .emacs.desktop file had one of the
> two values and it hung. When I edited the file and changed it to the
> other of the two values, it started flawlessly.
> XTERM=/usr/bin/X11/xterm -ls -sb -sl 4000 -display sundev28:37.0
> DISPLAY=sundev28:37.0
>
> Of course I don't understand the internals, but I don't understand why
> emacs starts up and tries to use a saved "display" value at all? Why
> doesn't it just always use the display value defined in the current
> shell in which I am invoking emacs? Perhaps this is sometimes
> desirable, but is there a setting I can use to make emacs ignore this
> value saved in the desktop file and always use the value from the
> current environment?


Maybe setting desktop-restore-in-current-display to t will help?

I suspect that in that variable's doc:

   If nil, restores frames into their original displays (if possible).

the "(if possible)" part is going to be tricky to get right.

See also http://debbugs.gnu.org/17693#40



[-- Attachment #2: Type: text/html, Size: 3002 bytes --]

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

I'm looking into Bug#20247 <http://bugs.gnu.org#20247>, currently listed 
as a blocker for Emacs 25. From the bug report, it appears that the 
attached patch would have prevented the bug. This patch is a change to 
Emacs behavior so I'll propose it here now, and give a heads-up on the 
Emacs-devel mailing list before installing it. Comments welcome. I don't 
care myself about the behavior one way or another (I don't use desktop 
mode) and am mainly just trying to clear out the bug backlog.


[-- Attachment #2: 0001-Restore-frames-into-the-current-display-by-default.patch --]
[-- Type: application/x-patch, Size: 1522 bytes --]

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Drew Adams]

> I'm looking into Bug#20247 <http://bugs.gnu.org#20247>, currently listed
> as a blocker for Emacs 25. From the bug report, it appears that the
> attached patch would have prevented the bug. This patch is a change to
> Emacs behavior so I'll propose it here now, and give a heads-up on the
> Emacs-devel mailing list before installing it. Comments welcome. I don't
> care myself about the behavior one way or another (I don't use desktop
> mode) and am mainly just trying to clear out the bug backlog.

This doesn't sound right, to me.  (To be clear, it does not affect my
own use of Emacs.)

Can we not leave the default to respecting the saved display value,
but also use a `condition-case' or similar to DTRT if that display
does not exist or trying to use it raises an error in some other way?

The proposed cure sounds like killing the patient.  IIUC, the problem
reported is that the recorded display value cannot be used in this
case.  Fine.  That's not a sufficient reason for defaulting to not
using the recorded display value.

And it doesn't solve the underlying problem for a user who decides
to customize the value to use the recorded display value.

A better fix, I think, would be to do something like this:

1. Leave the default as is (not specifically important to this bug,
however, as I mentioned: changing the default does NOT solve the
problem, AFAICT).

2. If the current value says to use the recorded display then try
to do that.  If an error is raised then do not use it.


I don't have the code for #2.  No doubt Someone (TM) would need to
_actually try to debug this_, to find out just what happens when a
bad display value is tried.

The OP reported that Emacs hangs.  Debugging would need to find
out just what goes on, and trap that problem as an error - raise
an error instead of hang.  Then the code to DTRT in this case,
which is to fall back to ignoring the display value that led to
the error, should be pretty simple.

The first task is for Someone (TM) to actually try to find out
what the problem is - what happens - when the display value is
inappropriate.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Paul Eggert]

On 05/20/2016 08:24 AM, Drew Adams wrote:
> A better fix, I think, would be to do something like this:

If someone has the time to develop an even-better patch, that would be 
great. In the meantime, the question is whether the proposed patch 
improves Emacs. I don't use desktop mode and don't know the pros and 
cons of the various settings. That being said, it appears that 
defaulting desktop-restore-in-current-display to nil caused significant 
misbehavior for a real use case, whereas defaulting to t would have 
worked for that use case. There is something to be said for choosing a 
default that is less likely to cause a bug, even if you have not fixed 
the bug in general.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Drew Adams]

> > A better fix, I think, would be to do something like this:
> 
> If someone has the time to develop an even-better patch, that would be
> great. In the meantime, the question is whether the proposed patch
> improves Emacs.

All your patch does is make the _default_ value be one that doesn't
manifest the bug.  That does not sound like a fix, to me.  I would
hardly even characterize it as an improvement, though admittedly
some users might be less likely to stumble on the bug.

To me, this is, at best, papering over the cracks - and the paper
is very thin.

I certainly hope that the bug remains open, so this can be fixed,
whether or not your patch gets applied.  The bug will still exist.

> I don't use desktop mode and don't know the pros and
> cons of the various settings.  That being said, it appears that
> defaulting desktop-restore-in-current-display to nil caused significant
> misbehavior for a real use case, whereas defaulting to t would have
> worked for that use case. There is something to be said for choosing a
> default that is less likely to cause a bug, even if you have not fixed
> the bug in general.

There might be something to be said for that, but it is not much, IMO.

My recommendation would be to leave the default value as it is and
leave the bug open until someone can debug it and fix it.  This bug
should not be a reason behind the default-value choice.

What's the hurry to close bugs that would motivate not fixing them?

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Eli Zaretskii]

> Date: Fri, 20 May 2016 08:24:04 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Richard Munitz <rmunitz1@bloomberg.net>, 20247@debbugs.gnu.org
> 
> Can we not leave the default to respecting the saved display value,
> but also use a `condition-case' or similar to DTRT if that display
> does not exist or trying to use it raises an error in some other way?

Can you explain why using display that is not the current one even
makes sense?

> The proposed cure sounds like killing the patient.

To me it sounds like the only sane behavior.

> And it doesn't solve the underlying problem for a user who decides
> to customize the value to use the recorded display value.

The assumption is that if such a customization produces problematic
behavior, users won't do that.

> A better fix, I think, would be to do something like this:
> 
> 1. Leave the default as is (not specifically important to this bug,
> however, as I mentioned: changing the default does NOT solve the
> problem, AFAICT).
> 
> 2. If the current value says to use the recorded display then try
> to do that.  If an error is raised then do not use it.

That's okay to try on master (if someone thinks it would be better),
but not on the release branch.  Note that trying to use it might
display some of the frames, which would then be tricky to remove, and
flashing them might not look good.

> I don't have the code for #2.  No doubt Someone (TM) would need to
> _actually try to debug this_, to find out just what happens when a
> bad display value is tried.

I think it's clear without any debugging.

> The first task is for Someone (TM) to actually try to find out
> what the problem is - what happens - when the display value is
> inappropriate.

The same thing that happens when you try to communicate with a machine
that is down or disconnected.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 20 May 2016 08:34:41 -0700
> Cc: Richard Munitz <rmunitz1@bloomberg.net>, 20247@debbugs.gnu.org
> 
> If someone has the time to develop an even-better patch, that would be 
> great. In the meantime, the question is whether the proposed patch 
> improves Emacs. I don't use desktop mode and don't know the pros and 
> cons of the various settings. That being said, it appears that 
> defaulting desktop-restore-in-current-display to nil caused significant 
> misbehavior for a real use case, whereas defaulting to t would have 
> worked for that use case. There is something to be said for choosing a 
> default that is less likely to cause a bug, even if you have not fixed 
> the bug in general.

I agree.  The fix sounds OK for the release branch, provided that it
solves the original problem.

Thanks.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Eli Zaretskii]

> Date: Fri, 20 May 2016 08:54:59 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Richard Munitz <rmunitz1@bloomberg.net>, 20247@debbugs.gnu.org
> 
> What's the hurry to close bugs that would motivate not fixing them?

The motivation is to make Emacs 25.1 safer and more robust.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Paul Eggert]

On 05/20/2016 08:54 AM, Drew Adams wrote:
> I certainly hope that the bug remains open, so this can be fixed,
> whether or not your patch gets applied.  The bug will still exist.

Sure, we can leave this bug open, open a new bug report against just the 
default value, make the new bug report a blocker for Emacs 25 instead of 
the current bug, install the short patch I suggested, and then close the 
new bug. That would suffice to remove the blocking bug.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Drew Adams]

> > Can we not leave the default to respecting the saved display value,
> > but also use a `condition-case' or similar to DTRT if that display
> > does not exist or trying to use it raises an error in some other way?
> 
> Can you explain why using display that is not the current one even
> makes sense?

Ask Juanma, or whoever else might have been responsible for designing
this aspect of desktop.

Desktop is designed to support exactly that, no?  You are apparently
questioning the design.  That's fair, but is it necessary to address
this bug?

Anyway, I can't speak to the reasons why desktop is designed as
it is.  I'm just assuming that the design is not insane, as you
seem to be suggesting (this part of) it is.

> > The proposed cure sounds like killing the patient.
> 
> To me it sounds like the only sane behavior.

It sounds like you think it is insane for desktop to ever
specify (record) or use a `display' entry.  If so, that sounds
like a design change for desktop.

Do you not think there was a reason to allow users to record
the display as part of a desktop record, and to restore the
desktop using that recorded display?  Can you not imagine such
a use case?  I can, but maybe I'm missing something.

Desktop records lots of stuff that might not be usable when
an attempt is made to restore the recorded desktop.  Normally,
it tries to be fault-tolerant during restoration, and back off
when trying to restore something doesn't work or seems to be
inappropriate in the restoration context.

I don't see how this problem is different, or why it should be
handled differently, especially by simply getting rid of any
ability to restore to a particular display.

As I said, this in no way affects how I use Emacs, personally.
But I'm guessing that there was a (good) reason for allowing
recording (and so restoring) a `display' value.  And I'm
guessing that some users might be taking advantage of it.

I don't see how this bug necessitates tossing that part of the
desktop design.  But apparently you do.

> > And it doesn't solve the underlying problem for a user who decides
> > to customize the value to use the recorded display value.
> 
> The assumption is that if such a customization produces problematic
> behavior, users won't do that.

If you take the view you seem to be taking, then why not simply
remove all desktop support for a `display' entry?  Why stop with
changing the default value of this option?  Fix the problem by
eliminating the cause altogether, not just as a default value.

> > A better fix, I think, would be to do something like this:
> >
> > 1. Leave the default as is (not specifically important to this bug,
> > however, as I mentioned: changing the default does NOT solve the
> > problem, AFAICT).
> >
> > 2. If the current value says to use the recorded display then try
> > to do that.  If an error is raised then do not use it.
> 
> That's okay to try on master (if someone thinks it would be better),
> but not on the release branch.  Note that trying to use it might
> display some of the frames, which would then be tricky to remove, and
> flashing them might not look good.

I don't doubt that it might be tricky to try to fix.

> > I don't have the code for #2.  No doubt Someone (TM) would need to
> > _actually try to debug this_, to find out just what happens when a
> > bad display value is tried.
> 
> I think it's clear without any debugging.

Really?  In that case, can you please make it raise an error instead
of hanging?  And if you can do that then I'm guessing it should be
pretty simple to DTRT and check for that error - and when it is raised
not try to restore to the recorded `display' entry.  No?

> > The first task is for Someone (TM) to actually try to find out
> > what the problem is - what happens - when the display value is
> > inappropriate.
> 
> The same thing that happens when you try to communicate with a machine
> that is down or disconnected.

So turn that eventuality into raising an error, and handle the error
by abandoning continuing to try to use that nonexistent/broken display.
IOW, act, when there is such an error, the way you apparently want
Emacs to act all the time: as if no `display' entry were recorded.

Again. I don't really care what you do with this bug, personally.
It just sounds like you are perhaps throwing out the baby (= desktop
support for `display' entries) with the bathwater.  The baby needs a
bath, sure, but s?he shouldn't be tossed out in the process, I think.

I'm done here.  Do what you will.  Just trying to help.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Eli Zaretskii]

> Date: Fri, 20 May 2016 10:15:53 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: eggert@cs.ucla.edu, rgm@gnu.org, rmunitz1@bloomberg.net,
>         20247@debbugs.gnu.org, lekktu@gmail.com
> 
> > > Can we not leave the default to respecting the saved display value,
> > > but also use a `condition-case' or similar to DTRT if that display
> > > does not exist or trying to use it raises an error in some other way?
> > 
> > Can you explain why using display that is not the current one even
> > makes sense?
> 
> Ask Juanma, or whoever else might have been responsible for designing
> this aspect of desktop.

Juanma is not the one who claims that the current default value is the
correct one; you are.  I hoped you could explain why you think so.

> Desktop is designed to support exactly that, no?  You are apparently
> questioning the design.

The design supports both values.  I question the default.  I don't
object to allow the other value if it is useful in some marginal use
cases.

> Desktop records lots of stuff that might not be usable when
> an attempt is made to restore the recorded desktop.

Actually, no, it doesn't.  It generally records only values that
should be usable.

> > > I don't have the code for #2.  No doubt Someone (TM) would need to
> > > _actually try to debug this_, to find out just what happens when a
> > > bad display value is tried.
> > 
> > I think it's clear without any debugging.
> 
> Really?  In that case, can you please make it raise an error instead
> of hanging?

I don't see how that is relevant.  Being able to explain the problem
doesn't necessarily mean a solution is at hand.

> Just trying to help.

You aren't.

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Drew Adams]

> Juanma is not the one who claims that the current default value is
> the correct one; you are.  I hoped you could explain why you think so.

No, I have not claimed that.  Not at all.

> > Desktop records lots of stuff that might not be usable when
> > an attempt is made to restore the recorded desktop.
> 
> Actually, no, it doesn't.  It generally records only values that
> should be usable.

"Generally" meaning mostly, maybe.  Yes, most of the values are
anodyne most of the time (like `display'?).

bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Paul Eggert]

As I suggested in <http://bugs.gnu.org/20247#37>, I have created a new 
bug report (Bug#23604) that now blocks the Emacs 25 release and which 
merely asks to change the default value of 
desktop-restore-in-current-display from nil to t, and I have removed 
Bug#20247 from the list of blockers for Emacs 25. Both bug reports 
remain open for now, but when the little patch in Bug#23604 is installed 
we can close Bug#23604 (thus removing a blocker) while leaving Bug#20247 
open.