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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#27210: closed (25.2; Recovering loaddefs.el with desktop-mode
 hangs when linum is on)
Date: Sun, 04 Jun 2017 16:32:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 04 Jun 2017 19:31:34 +0300
with message-id <83zidnaf4p.fsf <at> gnu.org>
and subject line Re: bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on
has caused the debbugs.gnu.org bug report #27210,
regarding 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
27210: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27210
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Pierre Neidhardt <ambrevar <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on
Date: Sat, 3 Jun 2017 15:29:11 +0100

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.

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 27210-done <at> debbugs.gnu.org, ambrevar <at> gmail.com
Subject: Re: bug#27210: 25.2;
 Recovering loaddefs.el with desktop-mode hangs when linum is on
Date: Sun, 04 Jun 2017 19:31:34 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 27210 <at> debbugs.gnu.org,  ambrevar <at> gmail.com
> Date: Sun, 04 Jun 2017 11:08:59 -0400
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

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