* bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode @ 2021-03-23 0:30 Gilles 2021-03-23 10:06 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Gilles @ 2021-03-23 0:30 UTC (permalink / raw) To: 47334 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)) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode 2021-03-23 0:30 bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode Gilles @ 2021-03-23 10:06 ` Eli Zaretskii 2021-03-28 1:06 ` Gilles 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2021-03-23 10:06 UTC (permalink / raw) To: Gilles; +Cc: 47334 > From: Gilles <gilles.usenet@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode 2021-03-23 10:06 ` Eli Zaretskii @ 2021-03-28 1:06 ` Gilles 2021-03-28 6:36 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Gilles @ 2021-03-28 1:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 47334 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode 2021-03-28 1:06 ` Gilles @ 2021-03-28 6:36 ` Eli Zaretskii 2021-03-28 14:25 ` Gilles 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2021-03-28 6:36 UTC (permalink / raw) To: Gilles; +Cc: 47334 > From: Gilles <gilles.usenet@gmail.com> > Date: Sun, 28 Mar 2021 03:06:25 +0200 > Cc: 47334@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode 2021-03-28 6:36 ` Eli Zaretskii @ 2021-03-28 14:25 ` Gilles 2021-03-28 14:58 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Gilles @ 2021-03-28 14:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 47334 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@gnu.org> wrote: > > > From: Gilles <gilles.usenet@gmail.com> > > Date: Sun, 28 Mar 2021 03:06:25 +0200 > > Cc: 47334@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode 2021-03-28 14:25 ` Gilles @ 2021-03-28 14:58 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2021-03-28 14:58 UTC (permalink / raw) To: Gilles; +Cc: 47334 > From: Gilles <gilles.usenet@gmail.com> > Date: Sun, 28 Mar 2021 16:25:08 +0200 > Cc: 47334@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-03-28 14:58 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-03-23 0:30 bug#47334: 27.1; Incompatibility between daemon, desktop and highlight-changes-mode Gilles 2021-03-23 10:06 ` Eli Zaretskii 2021-03-28 1:06 ` Gilles 2021-03-28 6:36 ` Eli Zaretskii 2021-03-28 14:25 ` Gilles 2021-03-28 14:58 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).