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