GNU bug report logs - #80157
30.2; GUD with GDB is now unusably slow when debugging LibreOffice

Previous Next

To reply to this bug, email your comments to 80157 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Neil Roberts <bpeeluk <at> yahoo.co.uk>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; GUD with GDB is now unusably slow when debugging LibreOffice
Date: Thu, 08 Jan 2026 20:48:45 +0100

Hi,

Since I upgraded to Fedora 43 I ended up on a newer version of Emacs and
now I can’t use GUD with GDB to debug LibreOffice any more. After a few
seconds of running LibreOffice in GDB, Emacs becomes very sluggish and
eats up 100% CPU even when nothing is happening. I think it is still
technically responding to key presses but you have to wait in the order
of 10 seconds between each key press before it will respond. It looks
like something is repeatedly installing an idle time out and it
constantly invokes the garbage collector.

I bisected it down to this commit:

commit e0dc60e07803f9859ad0008bae4b22d6452547b2
Author: Eli Zaretskii <eliz <at> gnu.org>
Date:   Tue Apr 18 14:36:28 2023 +0300

    ; Fix typos in gdb-mi.el
    
    * lisp/progmodes/gdb-mi.el (gdbmi-bnf-result-state-configs): Fix
    typos introduced while fixing bug#10580.  (Bug#62858)

 lisp/progmodes/gdb-mi.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Steps to reproduce:

• Make sure you have LibreOffice installed. You can use the one from
  your distro.
• Run “emacs -Q”
• Press M-x gdb <RET>
• Change the command line to:
  gdb -i=mi /usr/lib64/libreoffice/program/soffice.bin
• Press enter
• Answer no to the question about debuginfo
• Type “run” at the gdb prompt
• Use the newly opened LibreOffice for a few seconds, for example by
  creating a text document and writing something in it.
• Switch back to your Emacs window
• Try to move the cursor around. Notice that is extremely unresponsive
  to the point of being unusable.

In GNU Emacs 30.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
 3.24.51, cairo version 1.18.4) of 2025-11-15 built on
 4b05eb3b0d9741e2ba4ca1bfb3d7e711
System Description: Fedora Linux 43 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/bin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --disable-gc-mark-trace --with-cairo
 --with-dbus --with-gif --with-gpm=no --with-harfbuzz --with-jpeg
 --with-modules --with-native-compilation=aot --with-pgtk --with-png
 --with-rsvg --with-sqlite3 --with-tiff --with-tree-sitter --with-webp
 --with-xpm build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
 -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
 -mno-omit-leaf-frame-pointer ' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed
 -Wl,-z,pack-relative-relocs -Wl,-z,now
 -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
 -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
 -specs=/usr/lib/rpm/redhat/redhat-package-notes ' CXX=g++ 'CXXFLAGS=-O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
 -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
 -mno-omit-leaf-frame-pointer '
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: fr_FR.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  server-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug tabify man face-remap term/screen
term/xterm xterm sh-script smie executable shr-color textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check mm-archive
mule-util js c-ts-common treesit rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util
rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap sgml-mode facemenu
nxml-util nxml-enc xmltok make-mode pulse color find-func shortdoc
completion autoconf autoconf-mode vc-hg vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs log-view vc files-x grep etags fileloop generator xref
dired-aux bug-reference project ffap misearch multi-isearch filecache
whitespace magit-version gtags quail notmuch hl-line notmuch-message
notmuch-hello notmuch-tree notmuch-show notmuch-print notmuch-crypto
notmuch-mua notmuch-draft notmuch-maildir-fcc notmuch-address
notmuch-company notmuch-parser notmuch-wash coolj notmuch-query
goto-addr icalendar diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs notmuch-tag notmuch-lib notmuch-version notmuch-compat
gnus-html url-queue help-fns radix-tree url-cache mm-url gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill
kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus
gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time iso8601
gnus-spec gnus-int gnus-range gnus-win gnus nnheader range git-rebase
magit-submodule magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
package url-handlers magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff git-commit log-edit message
sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
magit-core magit-autorevert autorevert filenotify magit-margin
magit-transient magit-process with-editor comp comp-cstr warnings
comp-run comp-common rx shell pcomplete server magit-mode transient
cl-extra edmacro kmacro help-mode browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util url-parse auth-source password-cache url-vars
mailcap benchmark magit-git magit-base magit-section cl-seq format-spec
cursor-sensor crm eieio eieio-core dash compat pcase javadoc-help
thingatpt advice cus-edit pp cus-load icons color-theme-subdued
color-theme-neil-dark cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs compile
text-property-search comint ansi-osc ansi-color ring color-theme
wid-edit cl clang-include-fixer let-alist json subr-x map byte-opt
bytecomp byte-compile clang-format cl-macs gv vc-git diff-mode
track-changes easy-mmode vc-dispatcher xml cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win touch-screen pgtk-dnd 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 pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 4189776 374354) (symbols 48 34041 22)
 (strings 32 517276 27115) (string-bytes 1 17628536)
 (vectors 16 91628) (vector-slots 8 1078757 375605)
 (floats 8 702 13338) (intervals 56 442295 11894) (buffers 992 61))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Neil Roberts <bpeeluk <at> yahoo.co.uk>
Cc: 80157 <at> debbugs.gnu.org
Subject: Re: bug#80157: 30.2;
 GUD with GDB is now unusably slow when debugging LibreOffice
Date: Fri, 09 Jan 2026 09:33:50 +0200

> Date: Thu, 08 Jan 2026 20:48:45 +0100
> From:  Neil Roberts via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Since I upgraded to Fedora 43 I ended up on a newer version of Emacs and
> now I can’t use GUD with GDB to debug LibreOffice any more. After a few
> seconds of running LibreOffice in GDB, Emacs becomes very sluggish and
> eats up 100% CPU even when nothing is happening. I think it is still
> technically responding to key presses but you have to wait in the order
> of 10 seconds between each key press before it will respond. It looks
> like something is repeatedly installing an idle time out and it
> constantly invokes the garbage collector.
> 
> I bisected it down to this commit:
> 
> commit e0dc60e07803f9859ad0008bae4b22d6452547b2
> Author: Eli Zaretskii <eliz <at> gnu.org>
> Date:   Tue Apr 18 14:36:28 2023 +0300
> 
>     ; Fix typos in gdb-mi.el
>     
>     * lisp/progmodes/gdb-mi.el (gdbmi-bnf-result-state-configs): Fix
>     typos introduced while fixing bug#10580.  (Bug#62858)
> 
>  lisp/progmodes/gdb-mi.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

How can a typo fix cause a bug, I wonder?

Do you see a lot of "Thread NNNNN exited" messages when you debug
LibreOffice?

> Steps to reproduce:
> 
> • Make sure you have LibreOffice installed. You can use the one from
>   your distro.
> • Run “emacs -Q”
> • Press M-x gdb <RET>
> • Change the command line to:
>   gdb -i=mi /usr/lib64/libreoffice/program/soffice.bin
> • Press enter
> • Answer no to the question about debuginfo
> • Type “run” at the gdb prompt
> • Use the newly opened LibreOffice for a few seconds, for example by
>   creating a text document and writing something in it.
> • Switch back to your Emacs window
> • Try to move the cursor around. Notice that is extremely unresponsive
>   to the point of being unusable.

If debugging LibreOffice is the only practical way to reproduce this,
I would ask you to please produce a profile of Emacs while "M-x gdb"
session runs where you see this sluggishness.  To this end, after you
do this in the above recipe:

> • Switch back to your Emacs window

and _before_ you do this:

> • Try to move the cursor around. Notice that is extremely unresponsive
>   to the point of being unusable.

type "M-x profiler-start RET RET".  Then move the cursor or do
whatever else you are doing that behaves sluggishly.  Keep doing that
for about 20 sec or more, then type "M-profiler-report RET".  This
will show and select a window showing a buffer with the CPU profile.
Then type "M-x profiler-write-profile RET", select a file name to save
the profile, and post the resulting file (as a binary attachment)
here.

Some other important information which might help:

Please show the value of gdb-handler-alist when Emacs is sluggish like
that (using the M-: command), and show the list of timers (using the
"M-x list-timers" command).

And if you type "M-x gdb-many-windows RET" while the above happens,
and click the "Threads" button in the breakpoints window, how many
threads do you see there, if any?

Please also type

  M-x set-variable RET garbage-collection-messages RET t RET

and tell how often do you see "Garbage collecting..." messages in the
echo area, while Emacs is sluggish.  And what are your values of
gc-cons-threshold and of gc-cons-percentage?

Finally, please tell which version of GDB do you have installed.

Thanks.

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

From: Neil Roberts <bpeeluk <at> yahoo.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 80157 <at> debbugs.gnu.org
Subject: Re: bug#80157: 30.2; GUD with GDB is now unusably slow when
 debugging LibreOffice
Date: Fri, 09 Jan 2026 10:42:24 +0100

Thanks for the quick reply.

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

> How can a typo fix cause a bug, I wonder?

I think the commit message is quite misleading. The typo is in the name
of the handler for the thread exiting message, so the behaviour changes
from “do nothing when a thread exits” to “call a function that was
previously unused”. The function is calling gdb-wait-for-pending which
“checks every 0.5 seconds…” so it seems like a good candidate for
causing the bug. Interestingly in the discussion for bug #62858 you
asked the patch submitter whether they tested the patch with a
multi-threaded program and they just replied “no”.

> Do you see a lot of "Thread NNNNN exited" messages when you debug
> LibreOffice?

Yes.

After further experimenting I find I can also reproduce the bug if I
replace LibreOffice with this little program:

#include <pthread.h>
#include <stdlib.h>

static void *
thread_start(void *)
{
        return NULL;
}

int
main(int argc, char **argv)
{
        for (int i = 0; i < 1000; i++)
        {
                pthread_t thread_id;

                pthread_create(&thread_id,
                               NULL /* attr */,
                               thread_start,
                               NULL /* arg */);
                pthread_join(thread_id, NULL /* retval */);
        }

        return EXIT_SUCCESS;
}

> If debugging LibreOffice is the only practical way to reproduce this
> I would ask you to please produce a profile of Emacs […]

> […] type "M-x profiler-start RET RET"

I can try do this if it’s really necessary, but I think it will take an
excruciatingly long time because as soon as the bug is triggered it’s
really hard to type anything in Emacs. The sluggishness continues even
if I kill LibreOffice and quit gdb. Hopefully the above program is an
easier way to reproduce the bug instead.

> Finally, please tell which version of GDB do you have installed.

$ gdb --version
GNU gdb (Fedora Linux) 16.3-6.fc43

Regards,
– Neil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Neil Roberts <bpeeluk <at> yahoo.co.uk>
Cc: 80157 <at> debbugs.gnu.org
Subject: Re: bug#80157: 30.2; GUD with GDB is now unusably slow when
 debugging LibreOffice
Date: Fri, 09 Jan 2026 13:51:30 +0200

> From: Neil Roberts <bpeeluk <at> yahoo.co.uk>
> Cc: 80157 <at> debbugs.gnu.org
> Date: Fri, 09 Jan 2026 10:42:24 +0100
> 
> Thanks for the quick reply.
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > How can a typo fix cause a bug, I wonder?
> 
> I think the commit message is quite misleading. The typo is in the name
> of the handler for the thread exiting message, so the behaviour changes
> from “do nothing when a thread exits” to “call a function that was
> previously unused”.

That's not accurate.  The change did include a typo fix:

  -            ("thread-existed" . (gdb-ignored-notification . atomic))
  +            ("thread-exited" . (gdb-thread-exited . atomic))

There's no "thread-existed" even, of course.

I made gdb-thread-exited be the handler of that because otherwise that
function was completely unused, and I couldn't understand how the
thread-exit event is supposed to be handled without that.

As a temporary workaround, you could change gdb-thread-exited in the
above back to gdb-ignored-notification.  It would be interesting to
know whether that fixes the problem or not.

> The function is calling gdb-wait-for-pending which
> “checks every 0.5 seconds…” so it seems like a good candidate for
> causing the bug. Interestingly in the discussion for bug #62858 you
> asked the patch submitter whether they tested the patch with a
> multi-threaded program and they just replied “no”.

What matters here is how frequently threads exit, obviously, not just
whether there are multiple threads.  I'm debugging Emacs on Windows
(where it is a multi-threaded program) all the time, and never saw any
such sluggishness, FWIW.

> > Do you see a lot of "Thread NNNNN exited" messages when you debug
> > LibreOffice?
> 
> Yes.

So we have our suspect.

> > […] type "M-x profiler-start RET RET"
> 
> I can try do this if it’s really necessary, but I think it will take an
> excruciatingly long time because as soon as the bug is triggered it’s
> really hard to type anything in Emacs. The sluggishness continues even
> if I kill LibreOffice and quit gdb. Hopefully the above program is an
> easier way to reproduce the bug instead.

Would you please at least post the other information that I requested,
which should be easier to collect?  That is, this:

> Please show the value of gdb-handler-alist when Emacs is sluggish like
> that (using the M-: command), and show the list of timers (using the
> "M-x list-timers" command).
> 
> And if you type "M-x gdb-many-windows RET" while the above happens,
> and click the "Threads" button in the breakpoints window, how many
> threads do you see there, if any?
> 
> Please also type
> 
>   M-x set-variable RET garbage-collection-messages RET t RET
> 
> and tell how often do you see "Garbage collecting..." messages in the
> echo area, while Emacs is sluggish.  And what are your values of
> gc-cons-threshold and of gc-cons-percentage?

It could be that just by looking at that I (or someone else) will have
an idea regarding the possible fix.  Please understand that I don't
have access to a fedora system, and my access to GNU/Linux is limited
to running -nw sessions in Emacs, and there's no LibreOffice installed
there.  So it could be that reproducing what you see will be hard for
me, which is why I asked for that information, since for you the
problem happens all the time.

> > Finally, please tell which version of GDB do you have installed.
> 
> $ gdb --version
> GNU gdb (Fedora Linux) 16.3-6.fc43

Thanks.  Let's hope that the "-fc43" thing doesn't hide any
Fedora-local changes which could be a factor here.

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

From: Neil Roberts <bpeeluk <at> yahoo.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 80157 <at> debbugs.gnu.org
Subject: Re: bug#80157: 30.2; GUD with GDB is now unusably slow when
 debugging LibreOffice
Date: Sat, 10 Jan 2026 10:24:18 +0100

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

> Would you please at least post the other information that I requested,
> which should be easier to collect?  That is, this:
>
>> Please show the value of gdb-handler-alist when Emacs is sluggish like
>> that (using the M-: command)

gdb-handler-list is:

(#s(gdb-handler 23 #[128 r\300q\210\302\301^B")\207 [*threads of soffice.bin* gdb-thread-list-handler apply] 4 

(fn &rest ARGS)] (*threads of soffice.bin* . gdb-invalidate-threads)))

>> and show the list of timers (using the "M-x list-timers" command).

list-timers has 287 lines that look like this:

               0.3s            - #f(compiled-function () #<bytecode -0xc6dab935acfe32b> [#f(compiled-function () #<bytecode 0x19ac5e490c8f> [gdb-buf-publisher gdb-emit-signal update-threads]) gdb-handler-list cl-some gdb-handler-pending-trigger gdb-wait-for-pending])

and then this:

               4.0s            - undo-auto--boundary-timer
   *           0.1s            t show-paren-function
   *           0.5s            t #f(compiled-function () #<bytecode 0x135c484fb230a48a> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])


>> And if you type "M-x gdb-many-windows RET" while the above happens,
>> and click the "Threads" button in the breakpoints window, how many
>> threads do you see there, if any?

The threads window seems to be empty.

>> Please also type
>> 
>>   M-x set-variable RET garbage-collection-messages RET t RET
>> 
>> and tell how often do you see "Garbage collecting..." messages in the
>> echo area, while Emacs is sluggish.

If I do this then the echo area constantly has “Garbage collecting...”
with a flickering “done”, so I guess it is constantly collecting
garabage.

>> And what are your values of
>> gc-cons-threshold and of gc-cons-percentage?

800000 and 0.1

> Please understand that I don't have access to a fedora system, and my
> access to GNU/Linux is limited to running -nw sessions in Emacs, and
> there's no LibreOffice installed there.

You can also reproduce the bug if you compile the tiny program that I
put in my last email so you don’t need to install LibreOffice. I can
confirm the bug also happens with -nw, so the system you have access to
is probably enough to reproduce the bug.

I wonder if the problem is that the huge number of timers are starving
the main loop so it never gets a chance to process any of the gdb
handlers. If I change the gdb-thread-exited function to the one below so
that it only ever queues one update-threads signal at a time then the
bug no longer happens for me:

(let ((update-threads-queued nil))
  (defun gdb-thread-exited (_token output-field)
    "Handle =thread-exited async record.
Unset `gdb-thread-number' if current thread exited and update threads list."
    (let* ((thread-id (gdb-mi--field (gdb-mi--from-string output-field) 'id)))
      (if (string= gdb-thread-number thread-id)
          (gdb-setq-thread-number nil))
      ;; When we continue current thread and it quickly exits,
      ;; the pending triggers in gdb-handler-list left after gdb-running
      ;; disallow us to properly call -thread-info without --thread option.
      ;; Thus we need to use gdb-wait-for-pending.
      (when (not update-threads-queued)
        (setq update-threads-queued t)
        (gdb-wait-for-pending
         (lambda ()
           (setq update-threads-queued nil)
           (gdb-emit-signal gdb-buf-publisher 'update-threads)))))))

Regards,
– Neil

Message #22 received at 80157-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Neil Roberts <bpeeluk <at> yahoo.co.uk>
Cc: 80157-done <at> debbugs.gnu.org
Subject: Re: bug#80157: 30.2; GUD with GDB is now unusably slow when
 debugging LibreOffice
Date: Sun, 11 Jan 2026 17:24:16 +0200

> From: Neil Roberts <bpeeluk <at> yahoo.co.uk>
> Cc: 80157 <at> debbugs.gnu.org
> Date: Sat, 10 Jan 2026 10:24:18 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Would you please at least post the other information that I requested,
> > which should be easier to collect?  That is, this:
> >
> >> Please show the value of gdb-handler-alist when Emacs is sluggish like
> >> that (using the M-: command)
> 
> gdb-handler-list is:
> 
> (#s(gdb-handler 23 #[128 r\300q\210\302\301^B")\207 [*threads of soffice.bin* gdb-thread-list-handler apply] 4 
> 
> (fn &rest ARGS)] (*threads of soffice.bin* . gdb-invalidate-threads)))
> 
> >> and show the list of timers (using the "M-x list-timers" command).
> 
> list-timers has 287 lines that look like this:
> 
>                0.3s            - #f(compiled-function () #<bytecode -0xc6dab935acfe32b> [#f(compiled-function () #<bytecode 0x19ac5e490c8f> [gdb-buf-publisher gdb-emit-signal update-threads]) gdb-handler-list cl-some gdb-handler-pending-trigger gdb-wait-for-pending])
> 
> and then this:
> 
>                4.0s            - undo-auto--boundary-timer
>    *           0.1s            t show-paren-function
>    *           0.5s            t #f(compiled-function () #<bytecode 0x135c484fb230a48a> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
> 
> 
> >> And if you type "M-x gdb-many-windows RET" while the above happens,
> >> and click the "Threads" button in the breakpoints window, how many
> >> threads do you see there, if any?
> 
> The threads window seems to be empty.
> 
> >> Please also type
> >> 
> >>   M-x set-variable RET garbage-collection-messages RET t RET
> >> 
> >> and tell how often do you see "Garbage collecting..." messages in the
> >> echo area, while Emacs is sluggish.
> 
> If I do this then the echo area constantly has “Garbage collecting...”
> with a flickering “done”, so I guess it is constantly collecting
> garabage.
> 
> >> And what are your values of
> >> gc-cons-threshold and of gc-cons-percentage?
> 
> 800000 and 0.1
> 
> > Please understand that I don't have access to a fedora system, and my
> > access to GNU/Linux is limited to running -nw sessions in Emacs, and
> > there's no LibreOffice installed there.
> 
> You can also reproduce the bug if you compile the tiny program that I
> put in my last email so you don’t need to install LibreOffice. I can
> confirm the bug also happens with -nw, so the system you have access to
> is probably enough to reproduce the bug.
> 
> I wonder if the problem is that the huge number of timers are starving
> the main loop so it never gets a chance to process any of the gdb
> handlers. If I change the gdb-thread-exited function to the one below so
> that it only ever queues one update-threads signal at a time then the
> bug no longer happens for me:
> 
> (let ((update-threads-queued nil))
>   (defun gdb-thread-exited (_token output-field)
>     "Handle =thread-exited async record.
> Unset `gdb-thread-number' if current thread exited and update threads list."
>     (let* ((thread-id (gdb-mi--field (gdb-mi--from-string output-field) 'id)))
>       (if (string= gdb-thread-number thread-id)
>           (gdb-setq-thread-number nil))
>       ;; When we continue current thread and it quickly exits,
>       ;; the pending triggers in gdb-handler-list left after gdb-running
>       ;; disallow us to properly call -thread-info without --thread option.
>       ;; Thus we need to use gdb-wait-for-pending.
>       (when (not update-threads-queued)
>         (setq update-threads-queued t)
>         (gdb-wait-for-pending
>          (lambda ()
>            (setq update-threads-queued nil)
>            (gdb-emit-signal gdb-buf-publisher 'update-threads)))))))

Thanks, I've now installed a fix along these lines (which will appear
in Emacs 31.1), and I'm therefore closing the bug.

Previous Next

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