GNU bug report logs - #47334
27.1; Incompatibility between daemon, desktop and highlight-changes-mode

Previous Next

To reply to this bug, email your comments to 47334 AT debbugs.gnu.org.

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

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

From: Gilles <gilles.usenet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1;
 Incompatibility between daemon, desktop and highlight-changes-mode
Date: Tue, 23 Mar 2021 01:30:36 +0100

When restoring a desktop session where a buffer has
highlight-changes-mode enabled, if Emacs is starting in daemon mode, it
locks up before opening the socket. There is no error message.

If Emacs is not starting in daemon mode, or if the desktop session file
does not list highlight-changes-mode, everything is fine.

I have observed this problem both with Emacs 27.1 on macOS and with
Emacs 26.3 on Ubuntu 20.04. Below I give the server an explicit name for
convenience but this is optional to reproduce the bug.

Here is a precise recipe to reproduce. (Lines beginning with a letter
are shell commands; lines beginning with `|` are terminal output.)

mkdir -p /var/tmp/bugs/emacs-daemon-desktop-highlight-changes/.emacs.d
cd /var/tmp/bugs/emacs-daemon-desktop-highlight-changes
echo "(setq desktop-restore-frames nil)" >.emacs.d/init.el
echo "(desktop-save-mode)" >>.emacs.d/init.el
HOME=$PWD emacs --no-site-file -nw .emacs.d/init.el
# C-x C-c y ; Exit, saving the session
cp .emacs.d/.emacs.desktop desktop.ok.el
HOME=$PWD emacs --no-site-file --daemon=foo
| Wrote
/var/tmp/bugs/emacs-daemon-desktop-highlight-changes/.emacs.d/.emacs.desktop.lock
| Desktop: 1 frame, 1 buffer restored.
| Starting Emacs daemon.
emacsclient -s foo -c -nw
# C-x b RET ; Switch to init.el
# M-x highlight-changes-mode RET
# M-x kill-emacs RET
cp .emacs.d/.emacs.desktop desktop.bad.el
HOME=$PWD emacs --no-site-file --daemon=foo

At this point, there are two Emacs processes (the original one and its
daemon child), but they do not reach the point of creating the server
socket. No message is displayed on the terminal. On the other hand, if I
kill the Emacs processes and run ``HOME=$PWD emacs --no-site-file -nw``,
Emacs starts normally.

Here are the working (desktop.ok.el) and non-working (desktop.bad.el)
versions of .emacs.desktop from above.

----------------------------------------------------------------
;; -*- mode: emacs-lisp; lexical-binding:t; coding: utf-8-emacs; -*-
;; --------------------------------------------------------------------------
;; Desktop File for Emacs
;; --------------------------------------------------------------------------
;; Created Tue Mar 23 00:57:14 2021
;; Desktop file format version 208
;; Emacs version 27.1

;; Global section:
(setq desktop-saved-frameset nil)
(setq desktop-missing-file-warning nil)
(setq tags-file-name nil)
(setq tags-table-list nil)
(setq search-ring nil)
(setq regexp-search-ring nil)
(setq register-alist nil)
(setq file-name-history nil)

;; Buffer section -- buffers listed in same order as in buffer list:
(desktop-create-buffer 208
  "/var/tmp/bugs/emacs-daemon-desktop-highlight-changes/.emacs.d/init.el"
  "init.el"
  'emacs-lisp-mode
  '(eldoc-mode)
  1
  '(nil nil)
  nil
  nil
  '((buffer-display-time 24665 11993 439843 0)
(buffer-file-coding-system . prefer-utf-8-unix))
  '((mark-ring nil)))

----------------------------------------------------------------
;; -*- mode: emacs-lisp; lexical-binding:t; coding: utf-8-emacs; -*-
;; --------------------------------------------------------------------------
;; Desktop File for Emacs
;; --------------------------------------------------------------------------
;; Created Tue Mar 23 00:58:04 2021
;; Desktop file format version 208
;; Emacs version 27.1

;; Global section:
(setq desktop-saved-frameset nil)
(setq desktop-missing-file-warning nil)
(setq tags-file-name nil)
(setq tags-table-list nil)
(setq search-ring nil)
(setq regexp-search-ring nil)
(setq register-alist nil)
(setq file-name-history nil)

;; Buffer section -- buffers listed in same order as in buffer list:
(desktop-create-buffer 208
  "/var/tmp/bugs/emacs-daemon-desktop-highlight-changes/.emacs.d/init.el"
  "init.el"
  'emacs-lisp-mode
  '(eldoc-mode highlight-changes-mode)
  1
  '(nil nil)
  nil
  nil
  '((buffer-display-time 24665 12038 824402 0)
(buffer-file-coding-system . prefer-utf-8-unix)
(highlight-changes-mode . t))
  '((mark-ring nil)))

----------------------------------------------------------------

In GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS
appkit-1671.60 Version 10.14.6 (Build 18G95))
 of 2020-08-12 built on builder10-14.porkrind.org
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.2.3

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS JSON PDUMPER

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-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
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded 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
threads kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 44980 8398)
 (symbols 48 5927 1)
 (strings 32 15288 1607)
 (string-bytes 1 506711)
 (vectors 16 10173)
 (vector-slots 8 126873 5444)
 (floats 8 20 38)
 (intervals 56 191 0)
 (buffers 1000 11))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gilles <gilles.usenet <at> gmail.com>
Cc: 47334 <at> debbugs.gnu.org
Subject: Re: bug#47334: 27.1;
 Incompatibility between daemon, desktop and highlight-changes-mode
Date: Tue, 23 Mar 2021 12:06:59 +0200

> From: Gilles <gilles.usenet <at> gmail.com>
> Date: Tue, 23 Mar 2021 01:30:36 +0100
> 
> When restoring a desktop session where a buffer has
> highlight-changes-mode enabled, if Emacs is starting in daemon mode, it
> locks up before opening the socket. There is no error message.
> 
> If Emacs is not starting in daemon mode, or if the desktop session file
> does not list highlight-changes-mode, everything is fine.
> 
> I have observed this problem both with Emacs 27.1 on macOS and with
> Emacs 26.3 on Ubuntu 20.04. Below I give the server an explicit name for
> convenience but this is optional to reproduce the bug.
> 
> Here is a precise recipe to reproduce. (Lines beginning with a letter
> are shell commands; lines beginning with `|` are terminal output.)

Thanks.

Since you already have a working setup for reproducing the problem,
could you please attach GDB to the daemon when it hangs, and show
both a C-level and a Lisp-level backtrace?  (This could be tricky if
you don't have a working GDB installed on your macOS system, because
LLDB isn't supported by src/.gdbinit init file.  But maybe you could
do this on Ubuntu?)  This could go a long way towards identifying the
problematic piece of code.

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

From: Gilles <gilles.usenet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47334 <at> debbugs.gnu.org
Subject: Re: bug#47334: 27.1;
 Incompatibility between daemon, desktop and highlight-changes-mode
Date: Sun, 28 Mar 2021 03:06:25 +0200

Hello,

I've done some further debugging (analysis below) and can reproduce
the mute Emacs problem just by throwing an error from
`after-init-hook'. I filed a separate bug for that:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47439

The incompatibility between highlight-changes-mode, desktop and daemon
startup exists regardless of the daemon-not-starting bug since
highlight-changes-mode is not restored correctly. The
daemon-not-starting bug just made it harder to figure out what was
going on.

----------------------------------------------------------------

I built emacs-27.2 from source with debugging enabled on Linux (Ubuntu
20.04) / x84_64. I observe the same symptoms. Here's a backtrace. I
used src/.gdbinit and do get a Lisp backtrace if I attach to an Emacs
process with a non-empty Lisp call stack.

----------------------------------------------------------------
Breakpoint 1 at 0x55d190f50dbd: file emacs.c, line 379.
Breakpoint 2 at 0x55d190f026f6: file xterm.c, line 10145.
(gdb) bt
#0  0x00007fdb9e854246 in __pselect
    (nfds=8, readfds=0x7fff6656d800, writefds=0x7fff6656d880,
exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>)
    at ../sysdeps/unix/sysv/linux/pselect.c:48
#1  0x000055d19120dfbe in really_call_select (arg=0x7fff6656d6f0)
    at thread.c:586
#2  0x000055d1910740ff in flush_stack_call_func
    (func=0x55d19120def3 <really_call_select>, arg=0x7fff6656d6f0)
    at alloc.c:4951
#3  0x000055d19120e0ba in thread_select
    (func=0x7fdb9e854180 <__pselect>, max_fds=8, rfds=0x7fff6656d800,
wfds=0x7fff6656d880, efds=0x0, timeout=0x7fff6656de30, sigmask=0x0) at
thread.c:616
#4  0x000055d191276770 in xg_select
    (fds_lim=8, rfds=0x7fff6656dea0, wfds=0x7fff6656df20, efds=0x0,
timeout=0x7fff6656de30, sigmask=0x0) at xgselect.c:117
#5  0x000055d19117fc7c in wait_reading_process_output
    (time_limit=0, nsecs=0, read_kbd=-1, do_display=true,
wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at
process.c:5572
#6  0x000055d190f67260 in kbd_buffer_get_event
    (kbp=0x7fff6656e200, used_mouse_menu=0x7fff6656e805, end_time=0x0)
    at keyboard.c:3866
#7  0x000055d190f6189d in read_event_from_main_queue
    (end_time=0x0, local_getcjmp=0x7fff6656e610,
used_mouse_menu=0x7fff6656e805) at keyboard.c:2156
#8  0x000055d190f61cb3 in read_decoded_event_from_main_queue
    (end_time=0x0, local_getcjmp=0x7fff6656e610, prev_event=XIL(0),
used_mouse_menu=0x7fff6656e805) at keyboard.c:2220
#9  0x000055d190f64030 in read_char
    (commandflag=1, map=XIL(0x55d19260ac23), prev_event=XIL(0),
used_mouse_menu=0x7fff6656e805, end_time=0x0) at keyboard.c:2830
#10 0x000055d190f7673b in read_key_sequence
    (keybuf=0x7fff6656e9f0, prompt=XIL(0), dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false)
    at keyboard.c:9554
#11 0x000055d190f5ef70 in command_loop_1 () at keyboard.c:1350
#12 0x000055d1910d6339 in internal_condition_case
    (bfun=0x55d190f5ead2 <command_loop_1>, handlers=XIL(0x90),
hfun=0x55d190f5e082 <cmd_error>) at eval.c:1356
#13 0x000055d190f5e693 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#14 0x000055d1910d571c in internal_catch
    (tag=XIL(0xcc60), func=0x55d190f5e662 <command_loop_2>, arg=XIL(0))
    at eval.c:1117
#15 0x000055d190f5e62d in command_loop () at keyboard.c:1070
#16 0x000055d190f5db49 in recursive_edit_1 () at keyboard.c:714
#17 0x000055d190f5dd49 in Frecursive_edit () at keyboard.c:786
#18 0x000055d190f5375d in main (argc=3, argv=0x7fff6656ee78) at emacs.c:2067
(gdb) p *readfds
$1 = {
  fds_bits = {128, 0 <repeats 15 times>}
}
(gdb) p *writefds
$2 = {
  fds_bits = {0 <repeats 16 times>}
}
----------------------------------------------------------------

It appears that Emacs is waiting for input from an event object. I
have no idea what that event object is about, or why the daemon would
be waiting for input before starting the server.

----------------------------------------------------------------
$ ls -log /proc/1372320/fd
total 0
lrwx------ 1 64 Mar 28 00:25 0 -> /dev/pts/6
lrwx------ 1 64 Mar 28 00:25 1 -> /dev/pts/6
lrwx------ 1 64 Mar 28 00:25 2 -> /dev/pts/6
lrwx------ 1 64 Mar 28 00:25 3 -> 'anon_inode:[timerfd]'
l-wx------ 1 64 Mar 28 00:25 4 -> 'pipe:[510996821]'
lr-x------ 1 64 Mar 28 00:25 5 -> /var/lib/sss/mc/passwd
lrwx------ 1 64 Mar 28 00:25 6 -> 'anon_inode:[eventfd]'
lrwx------ 1 64 Mar 28 00:25 7 -> 'anon_inode:[eventfd]'
----------------------------------------------------------------

I added some crude tracing in the init file:
----------------------------------------------------------------
(shell-command "echo >>trace .emacs start")
(eval-after-load 'hilit-chg '(shell-command "echo >>trace hilit-chg loaded"))
(defun my-highlight-changes-mode-hook ()
  (shell-command (format "echo >>trace 'highlight-changes-mode=%s in
%s'" highlight-changes-mode (buffer-name))))
(add-hook 'highlight-changes-mode-hook 'my-highlight-changes-mode-hook)

(setq desktop-restore-frames nil)
(desktop-save-mode)
(require 'hilit-chg)

(shell-command "echo >>trace .emacs end")
----------------------------------------------------------------

The resulting trace is:
----------------------------------------------------------------
.emacs start
hilit-chg loaded
.emacs end
----------------------------------------------------------------

My understanding is that the entry from desktop.el to
`after-init-hook' restores the buffer in highlight-changes-mode, which
calls (x-display-grayscale-p), which errors out because the daemon
doesn't have an X display. And indeed I can reproduce the problem
without session restoration or hilit-chg.el: the problem appears if
after-init-hook throws an error.

Turning on highlight-changes-mode should not depend on the
capabilities of the current terminal or display, since this can change
as new frames are attached.

-- Gilles

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gilles <gilles.usenet <at> gmail.com>
Cc: 47334 <at> debbugs.gnu.org
Subject: Re: bug#47334: 27.1;
 Incompatibility between daemon, desktop and highlight-changes-mode
Date: Sun, 28 Mar 2021 09:36:16 +0300

> From: Gilles <gilles.usenet <at> gmail.com>
> Date: Sun, 28 Mar 2021 03:06:25 +0200
> Cc: 47334 <at> debbugs.gnu.org
> 
> It appears that Emacs is waiting for input from an event object. I
> have no idea what that event object is about, or why the daemon would
> be waiting for input before starting the server.

I'm guessing that Emacs asked a question and is waiting for the user
to answer it.  But since you don't show the Lisp backtrace, it's hard
to know for sure.  If you type "xbacktrace", does GDB show the Lisp
backtrace?

> Turning on highlight-changes-mode should not depend on the
> capabilities of the current terminal or display, since this can change
> as new frames are attached.

We don't yet know if this is the problem, and thus hypothesis is
inconsistent with the fact that Emacs is waiting for the user to
answer some question.

Thanks.

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

From: Gilles <gilles.usenet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47334 <at> debbugs.gnu.org
Subject: Re: bug#47334: 27.1;
 Incompatibility between daemon, desktop and highlight-changes-mode
Date: Sun, 28 Mar 2021 16:25:08 +0200

I did include the Lisp backtrace: it's empty.

I used src/.gdbinit from the Emacs source tree. Here's the output I get from
    gdb -batch -ex bt -ex xbacktrace ./emacs 1409856
at an idle "emacs -Q":

[New LWP 1409857]
[New LWP 1409858]
[New LWP 1409859]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f696c484246 in __pselect (nfds=9, readfds=0x7ffdf9113730,
writefds=0x7ffdf91137b0, exceptfds=0x0, timeout=<optimized out>,
sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:48
48      ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not
from terminal]
DISPLAY = :0
TERM = xterm
Breakpoint 1 at 0x55e20e9cddbd: file emacs.c, line 379.
Breakpoint 2 at 0x55e20e97f6f6: file xterm.c, line 10145.
#0  0x00007f696c484246 in __pselect (nfds=9, readfds=0x7ffdf9113730,
writefds=0x7ffdf91137b0, exceptfds=0x0, timeout=<optimized out>,
sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:48
#1  0x000055e20ec8afbe in really_call_select (arg=0x7ffdf9113620) at
thread.c:586
#2  0x000055e20eaf10ff in flush_stack_call_func (func=0x55e20ec8aef3
<really_call_select>, arg=0x7ffdf9113620) at alloc.c:4951
#3  0x000055e20ec8b0ba in thread_select (func=0x7f696c484180
<__pselect>, max_fds=9, rfds=0x7ffdf9113730, wfds=0x7ffdf91137b0,
efds=0x0, timeout=0x7ffdf9113d60, sigmask=0x0) at thread.c:616
#4  0x000055e20ecf3770 in xg_select (fds_lim=9, rfds=0x7ffdf9113dd0,
wfds=0x7ffdf9113e50, efds=0x0, timeout=0x7ffdf9113d60, sigmask=0x0) at
xgselect.c:117
#5  0x000055e20ebfcc7c in wait_reading_process_output (time_limit=0,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0),
wait_proc=0x0, just_wait_proc=0) at process.c:5572
#6  0x000055e20e9e4260 in kbd_buffer_get_event (kbp=0x7ffdf9114130,
used_mouse_menu=0x7ffdf9114735, end_time=0x0) at keyboard.c:3866
#7  0x000055e20e9de89d in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7ffdf9114540, used_mouse_menu=0x7ffdf9114735) at
keyboard.c:2156
#8  0x000055e20e9decb3 in read_decoded_event_from_main_queue
(end_time=0x0, local_getcjmp=0x7ffdf9114540, prev_event=XIL(0),
used_mouse_menu=0x7ffdf9114735) at keyboard.c:2220
#9  0x000055e20e9e1030 in read_char (commandflag=1,
map=XIL(0x55e210c8daa3), prev_event=XIL(0),
used_mouse_menu=0x7ffdf9114735, end_time=0x0) at keyboard.c:2830
#10 0x000055e20e9f373b in read_key_sequence (keybuf=0x7ffdf9114920,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9554
#11 0x000055e20e9dbf70 in command_loop_1 () at keyboard.c:1350
#12 0x000055e20eb53339 in internal_condition_case (bfun=0x55e20e9dbad2
<command_loop_1>, handlers=XIL(0x90), hfun=0x55e20e9db082 <cmd_error>)
at eval.c:1356
#13 0x000055e20e9db693 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#14 0x000055e20eb5271c in internal_catch (tag=XIL(0xcc60),
func=0x55e20e9db662 <command_loop_2>, arg=XIL(0)) at eval.c:1117
#15 0x000055e20e9db62d in command_loop () at keyboard.c:1070
#16 0x000055e20e9dab49 in recursive_edit_1 () at keyboard.c:714
#17 0x000055e20e9dad49 in Frecursive_edit () at keyboard.c:786
#18 0x000055e20e9d075d in main (argc=2, argv=0x7ffdf9114da8) at emacs.c:2067
[Inferior 1 (process 1409856) detached]

And after pressing C-x C-f in that Emacs instance so that it's showing
the find-file prompt:

[New LWP 1409857]
[New LWP 1409858]
[New LWP 1409859]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f696c484246 in __pselect (nfds=9, readfds=0x7ffdf9111050,
writefds=0x7ffdf91110d0, exceptfds=0x0, timeout=<optimized out>,
sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:48
48      ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not
from terminal]
DISPLAY = :0
TERM = xterm
Breakpoint 1 at 0x55e20e9cddbd: file emacs.c, line 379.
Breakpoint 2 at 0x55e20e97f6f6: file xterm.c, line 10145.
#0  0x00007f696c484246 in __pselect (nfds=9, readfds=0x7ffdf9111050,
writefds=0x7ffdf91110d0, exceptfds=0x0, timeout=<optimized out>,
sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:48
#1  0x000055e20ec8afbe in really_call_select (arg=0x7ffdf9110f40) at
thread.c:586
#2  0x000055e20eaf10ff in flush_stack_call_func (func=0x55e20ec8aef3
<really_call_select>, arg=0x7ffdf9110f40) at alloc.c:4951
#3  0x000055e20ec8b0ba in thread_select (func=0x7f696c484180
<__pselect>, max_fds=9, rfds=0x7ffdf9111050, wfds=0x7ffdf91110d0,
efds=0x0, timeout=0x7ffdf9111680, sigmask=0x0) at thread.c:616
#4  0x000055e20ecf3770 in xg_select (fds_lim=9, rfds=0x7ffdf91116f0,
wfds=0x7ffdf9111770, efds=0x0, timeout=0x7ffdf9111680, sigmask=0x0) at
xgselect.c:117
#5  0x000055e20ebfcc7c in wait_reading_process_output (time_limit=30,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0),
wait_proc=0x0, just_wait_proc=0) at process.c:5572
#6  0x000055e20e7bd946 in sit_for (timeout=make_fixnum(30),
reading=true, display_option=1) at dispnew.c:6064
#7  0x000055e20e9e098f in read_char (commandflag=1,
map=XIL(0x55e210f25583), prev_event=XIL(0),
used_mouse_menu=0x7ffdf9111d05, end_time=0x0) at keyboard.c:2738
#8  0x000055e20e9f373b in read_key_sequence (keybuf=0x7ffdf9111ef0,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9554
#9  0x000055e20e9dbf70 in command_loop_1 () at keyboard.c:1350
#10 0x000055e20eb53339 in internal_condition_case (bfun=0x55e20e9dbad2
<command_loop_1>, handlers=XIL(0x90), hfun=0x55e20e9db082 <cmd_error>)
at eval.c:1356
#11 0x000055e20e9db693 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#12 0x000055e20eb5271c in internal_catch (tag=XIL(0x5520),
func=0x55e20e9db662 <command_loop_2>, arg=XIL(0)) at eval.c:1117
#13 0x000055e20e9db5bd in command_loop () at keyboard.c:1062
#14 0x000055e20e9dab49 in recursive_edit_1 () at keyboard.c:714
#15 0x000055e20ea65f65 in read_minibuf (map=XIL(0x55e210f26463),
initial=XIL(0x55e210b75c74), prompt=XIL(0x7f69691842ac),
expflag=false, histvar=XIL(0x5c10), histpos=make_fixnum(0),
defalt=XIL(0x55e210afa4c4), allow_props=false,
inherit_input_method=false) at minibuf.c:664
#16 0x000055e20ea66bed in Fread_from_minibuffer
(prompt=XIL(0x7f69691842ac), initial_contents=XIL(0x55e210b75c74),
keymap=XIL(0x55e210f26463), read=XIL(0), hist=XIL(0x5c10),
default_value=XIL(0x55e210afa4c4), inherit_input_method=XIL(0)) at
minibuf.c:943
#17 0x000055e20eb57f53 in funcall_subr (subr=0x55e20f3745c0
<Sread_from_minibuffer>, numargs=7, args=0x7ffdf91124a0) at
eval.c:2888
#18 0x000055e20eb57840 in Ffuncall (nargs=8, args=0x7ffdf9112498) at eval.c:2795
#19 0x000055e20ebe2a43 in exec_byte_code (bytestr=XIL(0x7f696918da7c),
vector=XIL(0x7f6969189d15), maxdepth=make_fixnum(18),
args_template=make_fixnum(2050), nargs=8, args=0x7ffdf91129f8) at
bytecode.c:633
#20 0x000055e20eb58581 in funcall_lambda (fun=XIL(0x7f6969189ce5),
nargs=8, arg_vector=0x7ffdf91129b8) at eval.c:2990
#21 0x000055e20eb57884 in Ffuncall (nargs=9, args=0x7ffdf91129b0) at eval.c:2797
#22 0x000055e20ea68b4c in Fcompleting_read
(prompt=XIL(0x7f69691842ac), collection=XIL(0x298759c9ff28),
predicate=XIL(0x5a60), require_match=XIL(0x298759c85468),
initial_input=XIL(0x55e210b75c74), hist=XIL(0x5c10),
def=XIL(0x55e210afa4c4), inherit_input_method=XIL(0)) at
minibuf.c:1658
#23 0x000055e20eb57fba in funcall_subr (subr=0x55e20f3747c0
<Scompleting_read>, numargs=7, args=0x7ffdf9112bb0) at eval.c:2893
#24 0x000055e20eb57840 in Ffuncall (nargs=8, args=0x7ffdf9112ba8) at eval.c:2795
#25 0x000055e20ebe2a43 in exec_byte_code (bytestr=XIL(0x7f69692fbfac),
vector=XIL(0x7f69690924ad), maxdepth=make_fixnum(22),
args_template=make_fixnum(1537), nargs=6, args=0x7ffdf9113260) at
bytecode.c:633
#26 0x000055e20eb58581 in funcall_lambda (fun=XIL(0x7f696909247d),
nargs=6, arg_vector=0x7ffdf9113230) at eval.c:2990
#27 0x000055e20eb57884 in Ffuncall (nargs=7, args=0x7ffdf9113228) at eval.c:2797
#28 0x000055e20ebe2a43 in exec_byte_code (bytestr=XIL(0x7f69692fc05c),
vector=XIL(0x7f6969092435), maxdepth=make_fixnum(13),
args_template=make_fixnum(1537), nargs=4, args=0x7ffdf9113700) at
bytecode.c:633
#29 0x000055e20eb58581 in funcall_lambda (fun=XIL(0x7f6969092405),
nargs=4, arg_vector=0x7ffdf91136e0) at eval.c:2990
#30 0x000055e20eb57884 in Ffuncall (nargs=5, args=0x7ffdf91136d8) at eval.c:2797
#31 0x000055e20ebe2a43 in exec_byte_code (bytestr=XIL(0x7f69691872ec),
vector=XIL(0x7f69691872c5), maxdepth=make_fixnum(7),
args_template=make_fixnum(514), nargs=2, args=0x7ffdf9113b80) at
bytecode.c:633
#32 0x000055e20eb58581 in funcall_lambda (fun=XIL(0x7f6969187295),
nargs=2, arg_vector=0x7ffdf9113b70) at eval.c:2990
#33 0x000055e20eb57884 in Ffuncall (nargs=3, args=0x7ffdf9113b68) at eval.c:2797
#34 0x000055e20ebe2a43 in exec_byte_code (bytestr=XIL(0x7f696918734c),
vector=XIL(0x7f696921c03d), maxdepth=make_fixnum(3),
args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:633
#35 0x000055e20ebe1a3a in Fbyte_code (bytestr=XIL(0x7f696918734c),
vector=XIL(0x7f696921c03d), maxdepth=make_fixnum(3)) at bytecode.c:322
#36 0x000055e20eb55e6c in eval_sub (form=XIL(0x7f696921c00b)) at eval.c:2280
#37 0x000055e20eb55266 in Feval (form=XIL(0x7f696921c00b),
lexical=XIL(0)) at eval.c:2103
#38 0x000055e20eb4584f in Fcall_interactively
(function=XIL(0x298759e29538), record_flag=XIL(0),
keys=XIL(0x55e210ff6da5)) at callint.c:323
#39 0x000055e20eb57e25 in funcall_subr (subr=0x55e20f379900
<Scall_interactively>, numargs=3, args=0x7ffdf9114390) at eval.c:2873
#40 0x000055e20eb57840 in Ffuncall (nargs=4, args=0x7ffdf9114388) at eval.c:2795
#41 0x000055e20ebe2a43 in exec_byte_code (bytestr=XIL(0x7f6969228984),
vector=XIL(0x7f69692286dd), maxdepth=make_fixnum(13),
args_template=make_fixnum(1025), nargs=1, args=0x7ffdf91148c0) at
bytecode.c:633
#42 0x000055e20eb58581 in funcall_lambda (fun=XIL(0x7f69692286ad),
nargs=1, arg_vector=0x7ffdf91148b8) at eval.c:2990
#43 0x000055e20eb57884 in Ffuncall (nargs=2, args=0x7ffdf91148b0) at eval.c:2797
#44 0x000055e20eb5703f in call1 (fn=XIL(0x3d50),
arg1=XIL(0x298759e29538)) at eval.c:2655
#45 0x000055e20e9dc38d in command_loop_1 () at keyboard.c:1463
#46 0x000055e20eb53339 in internal_condition_case (bfun=0x55e20e9dbad2
<command_loop_1>, handlers=XIL(0x90), hfun=0x55e20e9db082 <cmd_error>)
at eval.c:1356
#47 0x000055e20e9db693 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#48 0x000055e20eb5271c in internal_catch (tag=XIL(0xcc60),
func=0x55e20e9db662 <command_loop_2>, arg=XIL(0)) at eval.c:1117
#49 0x000055e20e9db62d in command_loop () at keyboard.c:1070
#50 0x000055e20e9dab49 in recursive_edit_1 () at keyboard.c:714
#51 0x000055e20e9dad49 in Frecursive_edit () at keyboard.c:786
#52 0x000055e20e9d075d in main (argc=2, argv=0x7ffdf9114da8) at emacs.c:2067

Lisp Backtrace:
"read-from-minibuffer" (0xf91124a0)
"completing-read-default" (0xf91129b8)
"completing-read" (0xf9112bb0)
"read-file-name-default" (0xf9113230)
"read-file-name" (0xf91136e0)
"find-file-read-args" (0xf9113b70)
"byte-code" (0xf9113fa0)
"call-interactively" (0xf9114390)
"command-execute" (0xf91148b8)
"read-from-minibuffer" (0xf91124a0)
"completing-read-default" (0xf91129b8)
"completing-read" (0xf9112bb0)
"read-file-name-default" (0xf9113230)
"read-file-name" (0xf91136e0)
"find-file-read-args" (0xf9113b70)
"byte-code" (0xf9113fa0)
"call-interactively" (0xf9114390)
"command-execute" (0xf91148b8)
[Inferior 1 (process 1409856) detached]

I thought Emacs might be asking some question, but if so:
1. Either the question comes from C code or there's something unusual
about the context of the question that causes no Lisp backtrace to
show up.
2. A prompt is inconsistent with my reading of the code of
highlight-changes-mode, whereas an error is consistent.

Obviously it would be easier to fix #47439 first. I consider that one
more important. I originally encountered this bug when I logged in,
which runs an Emacs daemon and restores my session. Having one
buffer's modes not properly restored because highlight-changes-mode
errored out would be a very minor problem. Having the session only
partly restored because desktop-read errored out, but having a
backtrace including highlight-changes-mode and desktop-read, would
have made the problem easy to diagnose. Just having an Emacs process
that wasn't responding was painful.

-- Gilles

On Sun, 28 Mar 2021 at 08:36, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Gilles <gilles.usenet <at> gmail.com>
> > Date: Sun, 28 Mar 2021 03:06:25 +0200
> > Cc: 47334 <at> debbugs.gnu.org
> >
> > It appears that Emacs is waiting for input from an event object. I
> > have no idea what that event object is about, or why the daemon would
> > be waiting for input before starting the server.
>
> I'm guessing that Emacs asked a question and is waiting for the user
> to answer it.  But since you don't show the Lisp backtrace, it's hard
> to know for sure.  If you type "xbacktrace", does GDB show the Lisp
> backtrace?
>
> > Turning on highlight-changes-mode should not depend on the
> > capabilities of the current terminal or display, since this can change
> > as new frames are attached.
>
> We don't yet know if this is the problem, and thus hypothesis is
> inconsistent with the fact that Emacs is waiting for the user to
> answer some question.
>
> Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gilles <gilles.usenet <at> gmail.com>
Cc: 47334 <at> debbugs.gnu.org
Subject: Re: bug#47334: 27.1;
 Incompatibility between daemon, desktop and highlight-changes-mode
Date: Sun, 28 Mar 2021 17:58:51 +0300

> From: Gilles <gilles.usenet <at> gmail.com>
> Date: Sun, 28 Mar 2021 16:25:08 +0200
> Cc: 47334 <at> debbugs.gnu.org
> 
> I thought Emacs might be asking some question, but if so:
> 1. Either the question comes from C code or there's something unusual
> about the context of the question that causes no Lisp backtrace to
> show up.
> 2. A prompt is inconsistent with my reading of the code of
> highlight-changes-mode, whereas an error is consistent.

No, I think you are right: Emacs is just idle here, but since it
didn't start the server, you cannot connect to it.

Previous Next

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