GNU bug report logs - #70049
30.0.50; (server-running-p) in mode line freezes emacs

Previous Next

To reply to this bug, email your comments to 70049 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: "Pedro A. Aranda" <paaguti <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Thu, 28 Mar 2024 11:45:16 +0100

Place the following file as init.el in a directory (e.g. ~/.demacs.d)


---- cut here ----
;; Mode line settings

(defun server-running-indicator()
  (when (server-running-p) "S "))
;;  (unless (null server-process) "S "))

;; (setq-default mode-line-right-align-edge 'right-fringe)
(setq-default mode-line-format
              (list
                     '(:eval (propertize (server-running-indicator)
                                         'face 'mode-line-buffer-id))

                     mode-line-modified
                     " "
                     mode-line-buffer-identification
                     " "
                     mode-line-position))
---- cut here ----

run emacs as
/usr/bin/emacs --init-directory ~/.demacs.d

On the emacs window, click on the lower left corner and resize it with
the mouse. No hangs are observed.

Now, active server-mode with
M-x server-mode

Try again to resize the emacs window with the mouse. Emacs freezes.

This doesn't happen if you use the commented line
(unless (null server-process) "S "))
instead of the
(when (server-running-p) "S "))


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2024-03-28 built on ee9499c728de
Repository revision: f1fe13ea057237f5426c93876488cb95be86156c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12201001
System Description: Ubuntu 22.04.4 LTS

Configured using:
 'configure --prefix=/usr --program-suffix=30 --with-x
 --with-x-toolkit=gtk3 --with-cairo --with-compress-install
 --with-modules=yes --with-threads --with-included-regex --with-zlib
 --with-json --with-rsvg --with-small-ja-dic
 --with-native-compilation=aot --with-tree-sitter=no 'CFLAGS=-g -O2
 -ffile-prefix-map=/home/paag/emacs=. -flto=auto -ffat-lto-objects
 -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
 -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects
 -flto=auto -Wl,-z,relro''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: es_ES.UTF-8
  value of $LC_NUMERIC: es_ES.UTF-8
  value of $LC_TIME: es_ES.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides 
/usr/share/emacs/30.0.50/lisp/language/thai-word

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x 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 rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 51330 11727) (symbols 48 5230 0) (strings 32 13871 2528)
 (string-bytes 1 460407) (vectors 16 9073)
 (vector-slots 8 126676 10197) (floats 8 40 13) (intervals 56 375 16)
 (buffers 984 11))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Pedro A. Aranda" <paaguti <at> gmail.com>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Thu, 28 Mar 2024 13:46:01 +0200

> Date: Thu, 28 Mar 2024 11:45:16 +0100
> From: "Pedro A. Aranda" <paaguti <at> gmail.com>
> 
> Place the following file as init.el in a directory (e.g. ~/.demacs.d)
> 
> 
> ---- cut here ----
> ;; Mode line settings
> 
> (defun server-running-indicator()
>    (when (server-running-p) "S "))
> ;;  (unless (null server-process) "S "))
> 
> ;; (setq-default mode-line-right-align-edge 'right-fringe)
> (setq-default mode-line-format
>                (list
>                       '(:eval (propertize (server-running-indicator)
>                                           'face 'mode-line-buffer-id))
> 
>                       mode-line-modified
>                       " "
>                       mode-line-buffer-identification
>                       " "
>                       mode-line-position))
> ---- cut here ----
> 
> run emacs as
> /usr/bin/emacs --init-directory ~/.demacs.d
> 
> On the emacs window, click on the lower left corner and resize it with
> the mouse. No hangs are observed.
> 
> Now, active server-mode with
> M-x server-mode
> 
> Try again to resize the emacs window with the mouse. Emacs freezes.

I seem to be unable to reproduce this.

Does the freeze happen only if you resize the frame?  What if you just
drag the mode line to resize the window?

And when you say "freezes", does it mean Emacs uses 100% of a CPU's
execution unit, or does it mean it waits for something doing nothing?

Btw, in general, having arbitrary expressions in mode-line's :eval
form might definitely cause problems, since the mode line is called by
redisplay.

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

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Thu, 28 Mar 2024 17:03:36 +0100

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

Hey,

When I say freeze, I mean it becomes irresponsive and does not respond to
Ctrl-G and GNOME detects the situation, opening a 'force quit' dialog. It
also happens in macOS, and there I can only force quit emacs. I've opened
this bug, because there was something similar around putting a VC indicator
in the mode-line.

It might not be solvable, but at least I think it is worth discussing and
documenting. Who knows if this could not end in a DONT-DO sort of document,
which might also be of some merit and use.

Happy easter, /PA


On Thu, 28 Mar 2024 at 12:46, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 28 Mar 2024 11:45:16 +0100
> > From: "Pedro A. Aranda" <paaguti <at> gmail.com>
> >
> > Place the following file as init.el in a directory (e.g. ~/.demacs.d)
> >
> >
> > ---- cut here ----
> > ;; Mode line settings
> >
> > (defun server-running-indicator()
> >    (when (server-running-p) "S "))
> > ;;  (unless (null server-process) "S "))
> >
> > ;; (setq-default mode-line-right-align-edge 'right-fringe)
> > (setq-default mode-line-format
> >                (list
> >                       '(:eval (propertize (server-running-indicator)
> >                                           'face 'mode-line-buffer-id))
> >
> >                       mode-line-modified
> >                       " "
> >                       mode-line-buffer-identification
> >                       " "
> >                       mode-line-position))
> > ---- cut here ----
> >
> > run emacs as
> > /usr/bin/emacs --init-directory ~/.demacs.d
> >
> > On the emacs window, click on the lower left corner and resize it with
> > the mouse. No hangs are observed.
> >
> > Now, active server-mode with
> > M-x server-mode
> >
> > Try again to resize the emacs window with the mouse. Emacs freezes.
>
> I seem to be unable to reproduce this.
>
> Does the freeze happen only if you resize the frame?  What if you just
> drag the mode line to resize the window?
>
> And when you say "freezes", does it mean Emacs uses 100% of a CPU's
> execution unit, or does it mean it waits for something doing nothing?
>
> Btw, in general, having arbitrary expressions in mode-line's :eval
> form might definitely cause problems, since the mode line is called by
> redisplay.
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Thu, 28 Mar 2024 18:26:30 +0200

> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> Date: Thu, 28 Mar 2024 17:03:36 +0100
> Cc: 70049 <at> debbugs.gnu.org
> 
> When I say freeze, I mean it becomes irresponsive and does not respond to Ctrl-G and GNOME detects the
> situation, opening a 'force quit' dialog. It also happens in macOS, and there I can only force quit emacs. I've
> opened this bug, because there was something similar around putting a VC indicator in the mode-line. 

Can you look at the CPU meter and tell if Emacs consumes CPU in this
state or not?

> It might not be solvable, but at least I think it is worth discussing and documenting. Who knows if this could
> not end in a DONT-DO sort of document, which might also be of some merit and use.

Sure, we are discussing it and trying to figure out what causes this.

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

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Fri, 29 Mar 2024 07:37:32 +0100

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

Hi

On Thu, 28 Mar 2024 at 17:26, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> > Date: Thu, 28 Mar 2024 17:03:36 +0100
> > Cc: 70049 <at> debbugs.gnu.org
> >
> > When I say freeze, I mean it becomes irresponsive and does not respond
> to Ctrl-G and GNOME detects the
> > situation, opening a 'force quit' dialog. It also happens in macOS, and
> there I can only force quit emacs. I've
> > opened this bug, because there was something similar around putting a VC
> indicator in the mode-line.
>
> Can you look at the CPU meter and tell if Emacs consumes CPU in this
> state or not?
>
I've fired up the system monitor on my Ubuntu 22.04. waited the CPU curves
stabilised before activating server-mode,
then waited again until everything was quiet again and then resized Emacs
to trigger the 'Emacs is not responding'
dialog. There was no significant raise in CPU or memory consumption. Then
repeated the same with the process tab
and couldn't detect any significant change.

> It might not be solvable, but at least I think it is worth discussing and
> documenting. Who knows if this could
> > not end in a DONT-DO sort of document, which might also be of some merit
> and use.
>
> Sure, we are discussing it and trying to figure out what causes this.
>
 If I can be of any help, just let me know.

Best, /PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Fri, 29 Mar 2024 09:55:46 +0300

> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> Date: Fri, 29 Mar 2024 07:37:32 +0100
> Cc: 70049 <at> debbugs.gnu.org
> 
>  Can you look at the CPU meter and tell if Emacs consumes CPU in this
>  state or not?
> 
> I've fired up the system monitor on my Ubuntu 22.04. waited the CPU curves stabilised before activating
> server-mode, 
> then waited again until everything was quiet again and then resized Emacs to trigger the 'Emacs is not
> responding'
> dialog. There was no significant raise in CPU or memory consumption. Then repeated the same with the
> process tab
> and couldn't detect any significant change.

OK, thanks.  This means Emacs is waiting for something.

Can you provide the GDB backtrace from this situation?  To do this,
repeat your sequence that causes Emacs to freeze, then do the
following from a separate shell prompt:

  $ cd /path/to/emacs/src
  $ gdb -p PID
  GNU gdb (GDB) XY.Z
  Copyright (C) NNNN Free Software Foundation, Inc.
  ...
  (gdb) source .gdbinit
  (gdb) thread apply all bt

where PID is the process ID of the frozen Emacs process, and
/path/to/emacs/src is the absolute file name of the directory where
you have the Emacs C source files -- there is a .gdbinit file there
which will cause GDB to produce both C and Lisp backtrace when you
type the "bt" command at the (gdb) prompt.

Then post the results here.

Thanks.

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

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Fri, 29 Mar 2024 08:09:37 +0100

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

Hi Eli,

that may tabe a bit longer... I'm creating a .deb in a VM which I then
install on my system(s).
But on it!

Best, /PA

On Fri, 29 Mar 2024 at 07:55, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> > Date: Fri, 29 Mar 2024 07:37:32 +0100
> > Cc: 70049 <at> debbugs.gnu.org
> >
> >  Can you look at the CPU meter and tell if Emacs consumes CPU in this
> >  state or not?
> >
> > I've fired up the system monitor on my Ubuntu 22.04. waited the CPU
> curves stabilised before activating
> > server-mode,
> > then waited again until everything was quiet again and then resized
> Emacs to trigger the 'Emacs is not
> > responding'
> > dialog. There was no significant raise in CPU or memory consumption.
> Then repeated the same with the
> > process tab
> > and couldn't detect any significant change.
>
> OK, thanks.  This means Emacs is waiting for something.
>
> Can you provide the GDB backtrace from this situation?  To do this,
> repeat your sequence that causes Emacs to freeze, then do the
> following from a separate shell prompt:
>
>   $ cd /path/to/emacs/src
>   $ gdb -p PID
>   GNU gdb (GDB) XY.Z
>   Copyright (C) NNNN Free Software Foundation, Inc.
>   ...
>   (gdb) source .gdbinit
>   (gdb) thread apply all bt
>
> where PID is the process ID of the frozen Emacs process, and
> /path/to/emacs/src is the absolute file name of the directory where
> you have the Emacs C source files -- there is a .gdbinit file there
> which will cause GDB to produce both C and Lisp backtrace when you
> type the "bt" command at the (gdb) prompt.
>
> Then post the results here.
>
> Thanks.
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

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

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Mon, 1 Apr 2024 10:36:01 +0200

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

Followed all the steps, and crashed emacs but bt doesn't print out
anything...

Sorry, /PA

On Fri, 29 Mar 2024 at 08:09, Pedro Andres Aranda Gutierrez <
paaguti <at> gmail.com> wrote:

> Hi Eli,
>
> that may tabe a bit longer... I'm creating a .deb in a VM which I then
> install on my system(s).
> But on it!
>
> Best, /PA
>
> On Fri, 29 Mar 2024 at 07:55, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
>> > Date: Fri, 29 Mar 2024 07:37:32 +0100
>> > Cc: 70049 <at> debbugs.gnu.org
>> >
>> >  Can you look at the CPU meter and tell if Emacs consumes CPU in this
>> >  state or not?
>> >
>> > I've fired up the system monitor on my Ubuntu 22.04. waited the CPU
>> curves stabilised before activating
>> > server-mode,
>> > then waited again until everything was quiet again and then resized
>> Emacs to trigger the 'Emacs is not
>> > responding'
>> > dialog. There was no significant raise in CPU or memory consumption.
>> Then repeated the same with the
>> > process tab
>> > and couldn't detect any significant change.
>>
>> OK, thanks.  This means Emacs is waiting for something.
>>
>> Can you provide the GDB backtrace from this situation?  To do this,
>> repeat your sequence that causes Emacs to freeze, then do the
>> following from a separate shell prompt:
>>
>>   $ cd /path/to/emacs/src
>>   $ gdb -p PID
>>   GNU gdb (GDB) XY.Z
>>   Copyright (C) NNNN Free Software Foundation, Inc.
>>   ...
>>   (gdb) source .gdbinit
>>   (gdb) thread apply all bt
>>
>> where PID is the process ID of the frozen Emacs process, and
>> /path/to/emacs/src is the absolute file name of the directory where
>> you have the Emacs C source files -- there is a .gdbinit file there
>> which will cause GDB to produce both C and Lisp backtrace when you
>> type the "bt" command at the (gdb) prompt.
>>
>> Then post the results here.
>>
>> Thanks.
>>
>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Mon, 01 Apr 2024 14:34:44 +0300

> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> Date: Mon, 1 Apr 2024 10:36:01 +0200
> Cc: 70049 <at> debbugs.gnu.org
> 
> Followed all the steps, and crashed emacs but bt doesn't print out anything...

"Crashed"?  Originally you said Emacs freezes, but didn't say it
crashes.

Can you start Emacs from GDB to begin with, and then repeat the steps
to make it freeze?

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

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Wed, 10 Apr 2024 12:46:09 +0200

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

BTW, workaround just for the record:

```
(defun server-running-p()
  (and server-process (memq (process-status server-process)
                            '(connect listen open run))))
```
I got this from an old post and it still works without blocking emacs on
redisplay.

/PA

On Mon, 1 Apr 2024 at 13:34, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> > Date: Mon, 1 Apr 2024 10:36:01 +0200
> > Cc: 70049 <at> debbugs.gnu.org
> >
> > Followed all the steps, and crashed emacs but bt doesn't print out
> anything...
>
> "Crashed"?  Originally you said Emacs freezes, but didn't say it
> crashes.
>
> Can you start Emacs from GDB to begin with, and then repeat the steps
> to make it freeze?
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>, 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Fri, 28 Feb 2025 19:00:39 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
>> Date: Mon, 1 Apr 2024 10:36:01 +0200
>> Cc: 70049 <at> debbugs.gnu.org
>>
>> Followed all the steps, and crashed emacs but bt doesn't print out anything...
>
> "Crashed"?  Originally you said Emacs freezes, but didn't say it
> crashes.
>
> Can you start Emacs from GDB to begin with, and then repeat the steps
> to make it freeze?

We seem to need more information to make any progress here.

Any chance you could try to follow the steps above?

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

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Sat, 1 Mar 2025 07:17:41 +0100

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

Hi,

I think I bumped on (server-running-p), which doesn't seem
to be very mode-line friendly.
The workaround is working smoothly since I first reported.
I'm using it on FreeBSD, Linux and macOS, emacs-30 and master.

Feel free to include all this info in the documentation and close this bug,

Best, /PA

On Sat, 1 Mar 2025 at 04:00, Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> >> Date: Mon, 1 Apr 2024 10:36:01 +0200
> >> Cc: 70049 <at> debbugs.gnu.org
> >>
> >> Followed all the steps, and crashed emacs but bt doesn't print out
> anything...
> >
> > "Crashed"?  Originally you said Emacs freezes, but didn't say it
> > crashes.
> >
> > Can you start Emacs from GDB to begin with, and then repeat the steps
> > to make it freeze?
>
> We seem to need more information to make any progress here.
>
> Any chance you could try to follow the steps above?
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
Year 1 of the New Koprocracy

[Message part 2 (text/html, inline)]

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70049 <at> debbugs.gnu.org
Subject: Re: bug#70049: 30.0.50; (server-running-p) in mode line freezes emacs
Date: Sat, 1 Mar 2025 16:10:06 -0800

Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:

> I think I bumped on (server-running-p), which doesn't seem
> to be very mode-line friendly.
> The workaround is working smoothly since I first reported.
> I'm using it on FreeBSD, Linux and macOS, emacs-30 and master.
>
> Feel free to include all this info in the documentation and close this bug,

IIUC, the workaround to get it working in the mode line is to redefine
`server-running-p' like so:

    (defun server-running-p()
       (and server-process (memq (process-status server-process)
                                 '(connect listen open run))))

There are some problems, for example I don't know where to document
this, or if that is safe enough to recommend (for example, will it break
something else).

In general, we don't guarantee that you can run arbitrary Lisp code in
the mode line without running into issues.  Maybe this is just one use
case that we don't support.  I'm leaning towards considering the
workaround as documented (in this bug report), and closing this as
wontfix.

Any other opinions here?

Previous Next

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