bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Pierre Neidhardt]

With the following init file:

	(desktop-save-mode 1)
	(global-linum-mode)

I visit "/usr/share/emacs/25.2/lisp/loaddefs.el" and everything is fine.
I save the desktop session with `desktop-save-in-desktop-dir' and kill
Emacs.

On next start, this displays in the terminal

	Warning: due to a long standing Gtk+ bug
	http://bugzilla.gnome.org/show_bug.cgi?id=85715
	Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
	Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
	Note: file is write protected

and Emacs hangs for minutes at least, possibly forever, becoming a CPU hog. I
then have to kill Emacs.

The corresponding buffer entry in .emacs.desktop is the following:

	;; Buffer section -- buffers listed in same order as in buffer list:
	(desktop-create-buffer 208
	  "/usr/share/emacs/25.2/lisp/loaddefs.el"
	  "loaddefs.el"
	  'emacs-lisp-mode
	  '(linum-mode)
	  1
	  '(nil nil)
	  t
	  nil
	  '((buffer-file-coding-system . utf-8-unix))
	  '((mark-ring nil)))

If I remove the entry or if I disable linum-mode by commenting the corresponding
line in the init file, Emacs can start properly.





In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.10)
 of 2017-04-22 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description:	Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Load-path shadows:
None found.

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Eli Zaretskii]

> Date: Sat, 3 Jun 2017 15:29:11 +0100
> From: Pierre Neidhardt <ambrevar@gmail.com>
> 
> With the following init file:
> 
> 	(desktop-save-mode 1)
> 	(global-linum-mode)
> 
> I visit "/usr/share/emacs/25.2/lisp/loaddefs.el" and everything is fine.
> I save the desktop session with `desktop-save-in-desktop-dir' and kill
> Emacs.
> 
> On next start, this displays in the terminal
> 
> 	Warning: due to a long standing Gtk+ bug
> 	http://bugzilla.gnome.org/show_bug.cgi?id=85715
> 	Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
> 	Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
> 	Note: file is write protected
> 
> and Emacs hangs for minutes at least, possibly forever, becoming a CPU hog. I
> then have to kill Emacs.

Not reproducible here.  I suspect some memory-related issue, similar
to like bug#26952, since this is Arch Linux.

Can you try building the Emacs master branch?  If my guess is correct,
this problem will not exist there.

Thanks.

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Pierre Neidhardt]

On 17-06-03 17:56:00, Eli Zaretskii wrote:
> > Date: Sat, 3 Jun 2017 15:29:11 +0100
> > From: Pierre Neidhardt <ambrevar@gmail.com>
> >
> > With the following init file:
> >
> > 	(desktop-save-mode 1)
> > 	(global-linum-mode)
> >
> > I visit "/usr/share/emacs/25.2/lisp/loaddefs.el" and everything is fine.
> > I save the desktop session with `desktop-save-in-desktop-dir' and kill
> > Emacs.
> >
> > On next start, this displays in the terminal
> >
> > 	Warning: due to a long standing Gtk+ bug
> > 	http://bugzilla.gnome.org/show_bug.cgi?id=85715
> > 	Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
> > 	Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
> > 	Note: file is write protected
> >
> > and Emacs hangs for minutes at least, possibly forever, becoming a CPU hog. I
> > then have to kill Emacs.
>
> Not reproducible here.  I suspect some memory-related issue, similar
> to like bug#26952, since this is Arch Linux.

bug#26952 is on Debian, or am I missing something?

Memory-wise, it keeps growing indeed, albeit at a very slow pace. Running for a
minute it barely ate 1MB more.

> Can you try building the Emacs master branch?  If my guess is correct,
> this problem will not exist there.

I just did and the issue is still there.

I am sorry I forgot to mention that the issue only happens when running `emacs --daemon`.

--
Pierre Neidhardt

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[npostavs]

tags 27210 confirmed
quit

Pierre Neidhardt <ambrevar@gmail.com> writes:

> On 17-06-03 17:56:00, Eli Zaretskii wrote:
>> >
>> > With the following init file:
>> >
>> > 	(desktop-save-mode 1)
>> > 	(global-linum-mode)
>> >
>> > I visit "/usr/share/emacs/25.2/lisp/loaddefs.el" and everything is fine.
>> > I save the desktop session with `desktop-save-in-desktop-dir' and kill
>> > Emacs.
[...]
>> > and Emacs hangs for minutes at least, possibly forever, becoming a CPU hog. I
>> > then have to kill Emacs.
>
>> Can you try building the Emacs master branch?  If my guess is correct,
>> this problem will not exist there.
>
> I just did and the issue is still there.
>
> I am sorry I forgot to mention that the issue only happens when running `emacs --daemon`.

I can reproduce this, the problem seems to be that window-start and
window-end give the same answers as point-min and point-max respectively
when in daemon mode.  This causes linum-update-window to make overlays
for every line in the buffer.

    (defun linum-update-window (win)
      "Update line numbers for the portion visible in window WIN."
      (goto-char (window-start win))
      (let ((line (line-number-at-pos))
            (limit (window-end win t))
        [...]
        ;; Create an overlay (or reuse an existing one) for each
        ;; line visible in this window, if necessary.
        (while (and (not (eobp)) (< (point) limit))


(gdb) p current_buffer->name_ 
$11 = XIL(0x2ecd214)
(gdb) xpr
Lisp_String
$12 = (struct Lisp_String *) 0x2ecd210
"loaddefs.el"
(gdb) n
1614	  buf = w->contents;
(gdb) 
1615	  CHECK_BUFFER (buf);
(gdb) 
1616	  b = XBUFFER (buf);
(gdb) 
1618	  if (! NILP (update)
(gdb) 
1619	      && (windows_or_buffers_changed
(gdb) 
1628	      && !(noninteractive || FRAME_INITIAL_P (WINDOW_XFRAME (w))))
(gdb) 
1662	    XSETINT (value, BUF_Z (b) - w->window_end_pos);
(gdb) 
1664	  return value;
(gdb) p value
$13 = make_number(1203513)
(gdb) xbacktrace
"window-end" (0xffff74f0)
"linum-update-window" (0xffff7d68)
"mapc" (0xffff7f88)
"linum-update" (0xffff86d0)
"linum-after-scroll" (0xffff8ec8)
"set-window-buffer" (0xffff9130)
"switch-to-buffer" (0xffff98e0)
"desktop-restore-file-buffer" (0xffffa0f0)
"desktop-create-buffer" (0xffffa930)
"eval-buffer" (0xffffae80)
"load-with-code-conversion" (0xffffb698)
"load" (0xffffbac8)
"desktop-read" (0xffffc370)
0x1510fd0 PVEC_COMPILED
"run-hooks" (0xffffccd0)
"command-line" (0xffffdb48)
"normal-top-level" (0xffffe3c0)

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: Eli Zaretskii <eliz@gnu.org>,  27210@debbugs.gnu.org
> Date: Sat, 03 Jun 2017 13:43:45 -0400
> 
> I can reproduce this, the problem seems to be that window-start and
> window-end give the same answers as point-min and point-max respectively
> when in daemon mode.  This causes linum-update-window to make overlays
> for every line in the buffer.

So you are saying this just takes a lot of time, but will eventually
end?  If so, what is the bug here?

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Eli Zaretskii]

> Date: Sat, 03 Jun 2017 21:02:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 27210@debbugs.gnu.org, ambrevar@gmail.com
> 
> > I can reproduce this, the problem seems to be that window-start and
> > window-end give the same answers as point-min and point-max respectively
> > when in daemon mode.  This causes linum-update-window to make overlays
> > for every line in the buffer.
> 
> So you are saying this just takes a lot of time, but will eventually
> end?  If so, what is the bug here?

Or maybe we should do the below?

diff --git a/lisp/linum.el b/lisp/linum.el
index 8baa263..06165f2 100644
--- a/lisp/linum.el
+++ b/lisp/linum.el
@@ -112,7 +112,8 @@ linum-mode
 (define-globalized-minor-mode global-linum-mode linum-mode linum-on)
 
 (defun linum-on ()
-  (unless (minibufferp)
+  (unless (or (minibufferp)
+              (and (daemonp) (null (frame-parameter nil 'client))))
     (linum-mode 1)))
 
 (defun linum-delete-overlays ()

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

> Or maybe we should do the below?
>
> diff --git a/lisp/linum.el b/lisp/linum.el
> index 8baa263..06165f2 100644
> --- a/lisp/linum.el
> +++ b/lisp/linum.el
> @@ -112,7 +112,8 @@ linum-mode
>  (define-globalized-minor-mode global-linum-mode linum-mode linum-on)
>  
>  (defun linum-on ()
> -  (unless (minibufferp)
> +  (unless (or (minibufferp)
> +              (and (daemonp) (null (frame-parameter nil 'client))))
>      (linum-mode 1)))

It feels like the proper solution should be

modified   src/frame.c
@@ -903,7 +903,7 @@ make_initial_frame (void)
   tty_frame_count = 1;
   fset_name (f, build_pure_c_string ("F1"));
 
-  SET_FRAME_VISIBLE (f, 1);
+  SET_FRAME_VISIBLE (f, 0);
 
   f->output_method = terminal->type;
   f->terminal = terminal;

Because the hidden "F1" frame clearly isn't actually visible (and we
don't need to show line numbers on it).  But that just triggers
Bug#26912 "desktop-clear with emacs as daemon results in error on C-x 5
0" even without desktop-clear, so it's not an acceptable solution by
itself at least.

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[npostavs]

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

npostavs@users.sourceforge.net writes:

> Because the hidden "F1" frame clearly isn't actually visible (and we
> don't need to show line numbers on it).  But that just triggers
> Bug#26912 "desktop-clear with emacs as daemon results in error on C-x 5
> 0" even without desktop-clear, so it's not an acceptable solution by
> itself at least.

I've expanded on this approach, it seems to work, though it's possible
I'm overlooking some other place that assumes the initial frame is
visible.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 2651 bytes --]

From 129862e0621bf16e20ecc433e427b66626ba9bb8 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Sat, 3 Jun 2017 17:59:17 -0400
Subject: [PATCH v1] Make the initial frame invisible when in daemon mode
 (Bug#27210)

* src/emacs.c (main): When starting as a daemon, add `daemonp'
parameter to the initial frame.
* src/frame.c (make_initial_frame): Set the initial frame as
nonvisible when running in daemon mode.
(other_frames): Return true if one of the other frames has a non-nil
`daemonp' frame parameter.
(delete_frame): Don't allow deleting a frame with a `daemonp'
parameter.
---
 src/emacs.c | 3 +++
 src/frame.c | 9 +++++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/emacs.c b/src/emacs.c
index 49ebb81767..04bdf9ecdb 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1170,6 +1170,8 @@ main (int argc, char **argv)
 #endif /* MSDOS */
       if (dname_arg)
 	daemon_name = xstrdup (dname_arg);
+      Fmodify_frame_parameters (Qnil, Fcons (Fcons (Qdaemonp, Fdaemonp ()),
+                                             Fframe_parameters (Qnil)));
     }
 
 #if defined HAVE_PTHREAD && !defined SYSTEM_MALLOC \
@@ -2486,6 +2488,7 @@ syms_of_emacs (void)
   DEFSYM (Qrisky_local_variable, "risky-local-variable");
   DEFSYM (Qkill_emacs, "kill-emacs");
   DEFSYM (Qkill_emacs_hook, "kill-emacs-hook");
+  DEFSYM (Qdaemonp, "daemonp");
 
 #ifndef CANNOT_DUMP
   defsubr (&Sdump_emacs);
diff --git a/src/frame.c b/src/frame.c
index 4d17a071dc..4c670b5c7a 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -903,7 +903,7 @@ make_initial_frame (void)
   tty_frame_count = 1;
   fset_name (f, build_pure_c_string ("F1"));
 
-  SET_FRAME_VISIBLE (f, 1);
+  SET_FRAME_VISIBLE (f, !IS_DAEMON);
 
   f->output_method = terminal->type;
   f->terminal = terminal;
@@ -1605,7 +1605,10 @@ other_frames (struct frame *f, bool invisible, bool force)
 		      && (force
 			  /* Allow deleting the terminal frame when at
 			     least one X frame exists.  */
-			  || (FRAME_WINDOW_P (f1) && !FRAME_WINDOW_P (f))))))
+                          || (FRAME_WINDOW_P (f1) && !FRAME_WINDOW_P (f))
+                          /* Allow deleting the last frame if a
+                             "daemon frame" exists.  */
+                          || !NILP (Fframe_parameter (frame1, Qdaemonp))))))
 	    return true;
 	}
     }
@@ -1685,6 +1688,8 @@ delete_frame (Lisp_Object frame, Lisp_Object force)
       else
 	error ("Attempt to delete the only frame");
     }
+  else if (IS_DAEMON && !NILP (Fframe_parameter (frame, Qdaemonp)))
+      error ("Attempt to delete daemon's frame");
 
   XSETFRAME (frame, f);
 
-- 
2.11.1

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 27210@debbugs.gnu.org,  ambrevar@gmail.com
> Date: Sat, 03 Jun 2017 19:07:31 -0400
> 
> > Because the hidden "F1" frame clearly isn't actually visible (and we
> > don't need to show line numbers on it).  But that just triggers
> > Bug#26912 "desktop-clear with emacs as daemon results in error on C-x 5
> > 0" even without desktop-clear, so it's not an acceptable solution by
> > itself at least.
> 
> I've expanded on this approach, it seems to work, though it's possible
> I'm overlooking some other place that assumes the initial frame is
> visible.
> 
> >From 129862e0621bf16e20ecc433e427b66626ba9bb8 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Sat, 3 Jun 2017 17:59:17 -0400
> Subject: [PATCH v1] Make the initial frame invisible when in daemon mode
>  (Bug#27210)
> 
> * src/emacs.c (main): When starting as a daemon, add `daemonp'
> parameter to the initial frame.
> * src/frame.c (make_initial_frame): Set the initial frame as
> nonvisible when running in daemon mode.
> (other_frames): Return true if one of the other frames has a non-nil
> `daemonp' frame parameter.
> (delete_frame): Don't allow deleting a frame with a `daemonp'
> parameter.

I'm bothered by the possible unintended consequences of this, as we
are only starting to collect experience with the daemon, desktop
restoring, the various globalized modes, and the initial frame.  This
bug report is AFAIR the only one where that combination causes some
issues.  If similar cases will at some point start piling up, then I'd
agree we might need a common solution for them, but until then... it
sounds overkill to decide that the initial daemon frame be marked as
invisible, for the sake of this single use case.  And don't forget
that the initial frame is invisible in non-daemon sessions as well,
until some point during startup.

There are more than 70 references to FRAME_VISIBLE_P in the C sources,
and another 2 dozen references to frame-visible-p in Lisp sources --
sounds to me like a lot of potential for breaking stuff.

My alternative proposal is much simpler, is localized to linum.el, and
in a nutshell tests exactly the same condition, since any frame in a
daemon session that can be visible is by definition a client frame.
Do you see any disadvantages with installing that instead?

Thanks.

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

> And don't forget that the initial frame is invisible in non-daemon
> sessions as well, until some point during startup.

I don't understand, is this an objection?  It only seems to support
making the daemon frame invisible as well (i.e., the approach in my
patch).

> There are more than 70 references to FRAME_VISIBLE_P in the C sources,
> and another 2 dozen references to frame-visible-p in Lisp sources --
> sounds to me like a lot of potential for breaking stuff.
>
> My alternative proposal is much simpler, is localized to linum.el, and
> in a nutshell tests exactly the same condition, since any frame in a
> daemon session that can be visible is by definition a client frame.
> Do you see any disadvantages with installing that instead?

The only disadvantage is that we still have this invisible daemon frame
which is marked as visible.  I agree it's okay to apply your patch now
and see if we get some other similar problems later.

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 27210@debbugs.gnu.org,  ambrevar@gmail.com
> Date: Sun, 04 Jun 2017 11:08:59 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And don't forget that the initial frame is invisible in non-daemon
> > sessions as well, until some point during startup.
> 
> I don't understand, is this an objection?

Sorry for being unclear: I meant to point out that a non-daemon
startup initially has such a frame as well, and we never heard any
complaints about that.  Which might mean that some of the code
routinely run during startup expects to find that frame marked
visible.

> > My alternative proposal is much simpler, is localized to linum.el, and
> > in a nutshell tests exactly the same condition, since any frame in a
> > daemon session that can be visible is by definition a client frame.
> > Do you see any disadvantages with installing that instead?
> 
> The only disadvantage is that we still have this invisible daemon frame
> which is marked as visible.  I agree it's okay to apply your patch now
> and see if we get some other similar problems later.

OK, I've pushed the change.  Let's keep an eye on similar problems if
they pop up.