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@gnu.org> wrote:

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Fri, 29 Mar 2024 07:37:32 +0100
> Cc: 70049@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