GNU bug report logs -
#75461
30.0.93; Frequent (but inconsistent) hangs when creating frames
Previous Next
To reply to this bug, email your comments to 75461 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Thu, 09 Jan 2025 12:10:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Phil Sainty <psainty <at> orcon.net.nz>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 09 Jan 2025 12:10:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've recently switched my main instance of Emacs to 30.0 (firstly
30.0.93, and now the HEAD of the emacs-30 branch), and I've been
experiencing frequent hangs (with the CPU core spinning at 100% usage)
when creating new frames.
More specifically: when creating frames using a system I use with my
window manager when I want to interactively select a thing in a pop-up
Emacs frame. (I've tried to replicate this with simply "C-x 5 2" but
didn't manage to do so thus far.)
If I spam a terminal with a large number of "kill -USR2 <pid>" commands
for the spinning Emacs process ID, then I'll get control back.
I'm experiencing this (inconsistently, but quite often) with using a
keybinding for my window manager (XMonad), which runs a command like:
emacsclient --eval "(my-x-paste-example $(xdotool getactivewindow))"
With that command being something like:
(defun my-x-paste-example (wid)
(interactive)
(my-x-paste #'my-example wid "*Example*" "Testing"))
(defun my-example ()
(interactive)
(gui-backend-set-selection
'CLIPBOARD (completing-read "Choose: " '(one two three))))
I've attached the definition of `my-x-paste' to this report. It
creates a small floating frame for the interaction, and afterwards it
runs xdotool again to paste the clipboard contents into the X window
obtained by "xdotool getactivewindow", but I think the xdotool aspect
shouldn't be a factor, as it never gets that far -- Emacs creates the
frame and then immediately hangs before I can interact with it at all.
Perhaps the frame parameters used in that function are relevant,
though.
I've recompiled Emacs for debugging and run it under gdb, and have
reproduced a hang, so I have also attached some backtraces from gdb
(more than one because they're variable). In each case I used
"kill -TSTP <PID>" to stop Emacs spinning and drop to the gdb prompt,
and then the "backtrace" command. I then had to "continue" multiple
times before Emacs started running/spinning again, after which I
repeated the process.
(I also tried "xbacktrace" but that just said "Undefined command:
"xbacktrace". Try "help".", and I'm afraid that I only just saw the
"bt full" recommendation in the report-emacs-bug template -- the
etc/DEBUG file doesn't actually mention that command -- and I've not
been able to reproduce the issue in the interim to try that one, so
I'm sending this as-is for now.)
The function I'm calling in lisp does a `completing-read', and I can
see Fread_from_minibuffer in the backtrace, so I *guess* it's getting
that far after creating the frame; but I'm not sure if that's a factor
as (I think) I've also seen this with a pop-up notification frame
I use for appt.el notifications -- and that one doesn't prompt me at
all (but it's creating frames in a fairly similar way).
I can't replicate this at will, but it happens often enough that I
*should* be able to recreate it again sometime soon, so let me know
if you want me to try other things (but note that I'm not familiar
with gdb and debugging C code, so step-by-step instructions will be
helpful for that).
-Phil
In GNU Emacs 30.0.93 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw scroll bars) of 2025-01-09 built on phil-lp
Repository revision: 01464fc882dbb56d4271fbb89b7b847e8374d39c
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version
11.0.12101004
System Description: Ubuntu 22.04.5 LTS
Configured using:
'configure --prefix=/home/phil/emacs/30.x/usr/local
--without-native-compilation --with-x-toolkit=lucid --without-sound
'--program-transform-name=s/^ctags$/ctags_emacs/'
--enable-checking=yes,glyphs --enable-check-lisp-object-type
'CFLAGS=-O0 -g3''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM
XPM LUCID ZLIB
Important settings:
value of $LC_MONETARY: en_NZ.UTF-8
value of $LC_NUMERIC: en_NZ.UTF-8
value of $LC_TIME: en_NZ.UTF-8
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8
Major mode: IBuffer
Minor modes in effect:
text-scale-mode: t
hexl-follow-ascii: t
magit-wip-initial-backup-mode: t
magit-wip-before-change-mode: t
magit-wip-after-apply-mode: t
magit-wip-after-save-mode: t
magit-wip-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
catalyst-directory-event-icalendar-sync-mode: t
minibuffer-line-mode: t
global-edit-server-edit-mode: t
savehist-mode: t
global-anzu-mode: t
anzu-mode: t
my-contextual-help-mode: t
global-so-long-mode: t
server-mode: t
global-visible-mark-mode: t
visible-mark-mode: t
repeat-mode: t
display-battery-mode: t
my-visible-bell-mode: t
global-display-fill-column-indicator-mode: t
minibuffer-depth-indicate-mode: t
which-key-mode: t
winner-mode: t
keep-buffers-mode: t
global-subword-mode: t
subword-mode: t
global-hl-line-mode: t
display-time-mode: t
recentf-mode: t
global-atomic-chrome-edit-mode: t
my-global-keys-local-minor-mode: t
my-keys-local-minor-mode: t
windmove-mode: t
url-handler-mode: t
auto-compile-on-load-mode: t
auto-compile-on-save-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
minibuffer-regexp-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/phil/.emacs.d/el-get/scratch/el-get hides
/home/phil/.emacs.d/el-get/el-get/el-get
/home/phil/.emacs.d/el-get/avy/avy hides
/home/phil/.emacs.d/elpa/avy-0.5.0/avy
/home/phil/.emacs.d/el-get/dash/dash hides
/home/phil/.emacs.d/elpa/dash-2.19.1/dash
/home/phil/.emacs.d/el-get/iedit/iedit hides
/home/phil/.emacs.d/elpa/iedit-0.9.9.9.9/iedit
/home/phil/.emacs.d/my-lisp/psysh hides
/home/phil/.emacs.d/elpa/psysh-0.4.9/psysh
/home/phil/.emacs.d/elpa/transient-0.7.9/transient hides
/home/phil/emacs/30.x/usr/local/share/emacs/30.0.93/lisp/transient
/home/phil/.emacs.d/el-get/which-key/which-key hides
/home/phil/emacs/30.x/usr/local/share/emacs/30.0.93/lisp/which-key
Features:
(shadow sort ecomplete mail-extr emacsbug ibuf-ext ibuffer
ibuffer-loaddefs dired-aux face-remap pulse color help-fns xref project
hi-lock noutline outline find-func totp hexl executable magit-wip
magit-log which-func imenu magit-diff smerge-mode diff git-commit
log-edit message sendmail yank-media rfc822 mml mml-sec gnus-util
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader pcvs-util
add-log magit-core magit-autorevert autorevert filenotify magit-margin
magit-transient magit-process magit-mode transient edmacro compat
magit-git magit-section magit-utils crm dash mail-utils gnutls
network-stream url-cache epa-file epa epg rfc6068 epg-config view
holidays holiday-loaddefs cal-julian lunar solar cal-dst vc-git
diff-mode track-changes vc-dispatcher autoinsert bug-reference appt
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs lexbind-mode
hl-sexp fic-mode elide-head idle-highlight-mode catalyst-directory
vtable mule-util url-http url-auth mail-parse rfc2231 rfc2047 rfc2045
mm-util ietf-drums mail-prsvr url-gw nsm puny goto-addr sockit tabify
minibuffer-line edit-server my-org my-projects my-session savehist
desktop frameset my-theme zenburn-theme my-mail my-libraries sudo anzu
my-version-control my-text my-programming so-long my-rectangles rect
my-utilities with-editor server browse-kill-ring derived term disp-table
shell pcomplete ehelp my-configuration visible-mark cus-edit pp cus-load
dired-details dired-x repeat highlight-parentheses format-spec battery
delight delsel ffap thingatpt display-fill-column-indicator mb-depth
which-key pcase easy-mmode winner keep-buffers cap-words superword
subword hl-line time recentf tree-widget wid-edit atomic-chrome
websocket bindat let-alist my-whitespace ws-trim my-externals .loaddefs
rainbow-mode notify dbus xml mo-git-blame cl iedit el-get cl-extra
help-mode autoload loaddefs-gen radix-tree lisp-mnt dired dired-loaddefs
my-holidays my-local kmacro my-mahara grep tks generic-x catalyst
redshift-indent my-keybindings framemove advice windmove my-startup-log
trace cl-print time-date adaptive-wrap-autoloads dape-autoloads
docker-autoloads dockerfile-mode-autoloads eat-autoloads
eldoc-box-autoloads elfeed-autoloads haskell-mode-autoloads
helpful-autoloads elisp-refs-autoloads f-autoloads iedit-autoloads rx
modus-themes-autoloads psysh-autoloads rfc-mode-autoloads s-autoloads
markdown-mode-autoloads tablist-autoloads info transient-autoloads
visual-fill-autoloads websocket-autoloads wtf-autoloads xr-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source ...)
Memory information:
((conses 16 342345 195376) (symbols 48 38691 4)
(strings 32 146239 28849) (string-bytes 1 3881004) (vectors 16 64057)
(vector-slots 8 1530248 160628) (floats 8 907 8658)
(intervals 56 9801 2166) (buffers 992 27))
[my-x-paste.el (text/x-lisp, attachment)]
[backtrace1.txt.gz (application/x-gzip, attachment)]
[backtrace2.txt.gz (application/x-gzip, attachment)]
[backtrace3.txt.gz (application/x-gzip, attachment)]
[backtrace4.txt.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Thu, 09 Jan 2025 13:13:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 10 Jan 2025 01:09:20 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
>
> I've recently switched my main instance of Emacs to 30.0 (firstly
> 30.0.93, and now the HEAD of the emacs-30 branch), and I've been
> experiencing frequent hangs (with the CPU core spinning at 100% usage)
> when creating new frames.
>
> More specifically: when creating frames using a system I use with my
> window manager when I want to interactively select a thing in a pop-up
> Emacs frame. (I've tried to replicate this with simply "C-x 5 2" but
> didn't manage to do so thus far.)
>
> If I spam a terminal with a large number of "kill -USR2 <pid>" commands
> for the spinning Emacs process ID, then I'll get control back.
>
> I'm experiencing this (inconsistently, but quite often) with using a
> keybinding for my window manager (XMonad), which runs a command like:
>
> emacsclient --eval "(my-x-paste-example $(xdotool getactivewindow))"
>
> With that command being something like:
>
> (defun my-x-paste-example (wid)
> (interactive)
> (my-x-paste #'my-example wid "*Example*" "Testing"))
>
> (defun my-example ()
> (interactive)
> (gui-backend-set-selection
> 'CLIPBOARD (completing-read "Choose: " '(one two three))))
>
> I've attached the definition of `my-x-paste' to this report. It
> creates a small floating frame for the interaction, and afterwards it
> runs xdotool again to paste the clipboard contents into the X window
> obtained by "xdotool getactivewindow", but I think the xdotool aspect
> shouldn't be a factor, as it never gets that far -- Emacs creates the
> frame and then immediately hangs before I can interact with it at all.
> Perhaps the frame parameters used in that function are relevant,
> though.
>
> I've recompiled Emacs for debugging and run it under gdb, and have
> reproduced a hang, so I have also attached some backtraces from gdb
> (more than one because they're variable). In each case I used
> "kill -TSTP <PID>" to stop Emacs spinning and drop to the gdb prompt,
> and then the "backtrace" command. I then had to "continue" multiple
> times before Emacs started running/spinning again, after which I
> repeated the process.
>
> (I also tried "xbacktrace" but that just said "Undefined command:
> "xbacktrace". Try "help".", and I'm afraid that I only just saw the
> "bt full" recommendation in the report-emacs-bug template -- the
> etc/DEBUG file doesn't actually mention that command -- and I've not
> been able to reproduce the issue in the interim to try that one, so
> I'm sending this as-is for now.)
>
> The function I'm calling in lisp does a `completing-read', and I can
> see Fread_from_minibuffer in the backtrace, so I *guess* it's getting
> that far after creating the frame; but I'm not sure if that's a factor
> as (I think) I've also seen this with a pop-up notification frame
> I use for appt.el notifications -- and that one doesn't prompt me at
> all (but it's creating frames in a fairly similar way).
>
> I can't replicate this at will, but it happens often enough that I
> *should* be able to recreate it again sometime soon, so let me know
> if you want me to try other things (but note that I'm not familiar
> with gdb and debugging C code, so step-by-step instructions will be
> helpful for that).
Run Emacs normally, not from GD, and when it hangs attach GDB to it
and say
(gdb) thread apply all bt
Then post here everything GDB produces. (It is best to run GDB from
the src directory of the Emacs source tree, where it will read the
.gdbinit file which helps displaying Lisp objects.)
If we don't see from the first backtrace you produce what is the
problem, then do the above several times, so we could see some pattern
of where it hangs.
Btw, by "hangs" you mean it is stuck doing nothing, right? It doesn't
use 100% of some CPU execution unit (that would be "infloops", not
"hangs"), right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Thu, 09 Jan 2025 13:26:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 75461 <at> debbugs.gnu.org (full text, mbox):
Well I don't know what the connection is, but I've now realised that
this seems to happen only when my *mu4e-headers* buffer (for the mu4e
email client) is visible. As soon as I opened that I could reproduce
the problem again, and it seems to be a consistent trigger.
I'm using the version of mu4e which is packaged for Ubuntu 22.04:
Package: mu4e
Source: maildir-utils
Version: 1.4.15-1
That version is a few years old -- https://www.djcbsoftware.nl/code/mu/
says mu/mu4e 1.4 was released on 2020-04-18 -- but I'm using that
version to align with the packaged version of mu itself (the Ubuntu
package name for that one is "maildir-utils"), so I can't trivially
switch to a newer release.
On 2025-01-10 02:12, Eli Zaretskii wrote:
> Btw, by "hangs" you mean it is stuck doing nothing, right? It
> doesn't use 100% of some CPU execution unit (that would be
> "infloops", not "hangs"), right?
No, I did mean an infinite loop (the "hang" was that this causes
the user interface to freeze up unless I signal the process).
> Run Emacs normally, not from GD, and when it hangs attach GDB to it
> and say
>
> (gdb) thread apply all bt
>
> Then post here everything GDB produces.
Ok. It's too late to continue with this right now, so I'll follow
this up later...
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Thu, 09 Jan 2025 14:19:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 10 Jan 2025 02:25:51 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: 75461 <at> debbugs.gnu.org
>
> On 2025-01-10 02:12, Eli Zaretskii wrote:
> > Btw, by "hangs" you mean it is stuck doing nothing, right? It
> > doesn't use 100% of some CPU execution unit (that would be
> > "infloops", not "hangs"), right?
>
> No, I did mean an infinite loop (the "hang" was that this causes
> the user interface to freeze up unless I signal the process).
If it's an infloop, please follow the steps described in etc/DEBUG
under "If the symptom of the bug is that Emacs fails to respond".
> > Run Emacs normally, not from GD, and when it hangs attach GDB to it
^^
That was meant to be "GDB", of course.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sat, 22 Feb 2025 13:52:09 GMT)
Full text and
rfc822 format available.
Message #17 received at 75461 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
On 2025-01-10 03:18, Eli Zaretskii wrote:
> If it's an infloop, please follow the steps described in etc/DEBUG
> under "If the symptom of the bug is that Emacs fails to respond".
After attaching GDB and running 'finish' repeatedly, it looks like
it's failing to exit from redisplay_internal. It doesn't come back
to the gdb prompt after this message:
Run till exit from #0 0x000059a26b4124af in redisplay_internal () at
xdisp.c:17390
After repeating the process to get back to that frame, I stepped
through that function with 'next', and it's hitting the "goto
retry_frame;"
for the "if (FRAME_GARBAGED_P (f))" condition every time:
retry_frame:
if (FRAME_WINDOW_P (f) || FRAME_TERMCAP_P (f) || f == sf)
{
[...]
if (FRAME_REDISPLAY_P (f) && !FRAME_OBSCURED_P (f))
{
[...]
/* On some platforms (at least MS-Windows), the
scroll_run_hook called from scrolling_window
called from update_frame could set the frame's
garbaged flag, in which case we need to redisplay
the frame. Don't do that on TTY frames, since we
need to keep the garbaged flag in that case when
the frame has been resized. */
if (FRAME_GARBAGED_P (f))
{
fset_redisplay (f);
f->garbaged = false;
-> goto retry_frame;
}
f->cursor_type_changed = false;
f->updated_p = true;
f->inhibit_clear_image_cache = false;
}
}
By printing "f->garbaged" I can see that it's false up to the
following, and true after this call to redisplay_windows:
if (FRAME_REDISPLAY_P (f) && !FRAME_OBSCURED_P (f))
{
/* Don't allow freeing images and faces for this
frame as long as the frame's update wasn't
completed. This prevents crashes when some Lisp
that runs from the various hooks or font-lock
decides to clear the frame's image cache and face
cache, when the images and faces in those caches
are referenced by the desired matrix. */
f->inhibit_clear_image_cache = true;
-> redisplay_windows (FRAME_ROOT_WINDOW (f));
}
$ emacs-30.x --version
GNU Emacs 30.1
Development version 92e96a117525 on emacs-30 branch; build date
2025-02-20.
What would you like me to do from here?
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sat, 22 Feb 2025 14:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 23 Feb 2025 02:51:55 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: 75461 <at> debbugs.gnu.org
>
> Hi Eli,
>
> On 2025-01-10 03:18, Eli Zaretskii wrote:
> > If it's an infloop, please follow the steps described in etc/DEBUG
> > under "If the symptom of the bug is that Emacs fails to respond".
>
> After attaching GDB and running 'finish' repeatedly, it looks like
> it's failing to exit from redisplay_internal. It doesn't come back
> to the gdb prompt after this message:
>
> Run till exit from #0 0x000059a26b4124af in redisplay_internal () at
> xdisp.c:17390
>
> After repeating the process to get back to that frame, I stepped
> through that function with 'next', and it's hitting the "goto
> retry_frame;"
> for the "if (FRAME_GARBAGED_P (f))" condition every time:
>
>
> retry_frame:
> if (FRAME_WINDOW_P (f) || FRAME_TERMCAP_P (f) || f == sf)
> {
> [...]
>
> if (FRAME_REDISPLAY_P (f) && !FRAME_OBSCURED_P (f))
> {
> [...]
>
> /* On some platforms (at least MS-Windows), the
> scroll_run_hook called from scrolling_window
> called from update_frame could set the frame's
> garbaged flag, in which case we need to redisplay
> the frame. Don't do that on TTY frames, since we
> need to keep the garbaged flag in that case when
> the frame has been resized. */
> if (FRAME_GARBAGED_P (f))
> {
> fset_redisplay (f);
> f->garbaged = false;
> -> goto retry_frame;
> }
> f->cursor_type_changed = false;
> f->updated_p = true;
> f->inhibit_clear_image_cache = false;
> }
> }
>
>
>
>
> By printing "f->garbaged" I can see that it's false up to the
> following, and true after this call to redisplay_windows:
>
> if (FRAME_REDISPLAY_P (f) && !FRAME_OBSCURED_P (f))
> {
> /* Don't allow freeing images and faces for this
> frame as long as the frame's update wasn't
> completed. This prevents crashes when some Lisp
> that runs from the various hooks or font-lock
> decides to clear the frame's image cache and face
> cache, when the images and faces in those caches
> are referenced by the desired matrix. */
> f->inhibit_clear_image_cache = true;
> -> redisplay_windows (FRAME_ROOT_WINDOW (f));
> }
>
>
>
>
> $ emacs-30.x --version
> GNU Emacs 30.1
> Development version 92e96a117525 on emacs-30 branch; build date
> 2025-02-20.
>
>
> What would you like me to do from here?
I have no idea, it sounds like some issue with the window manager?
maybe martin (CC'ed) could help.
Do you have a simple enough recipe to reproduce this starting from
"emacs -Q"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sat, 22 Feb 2025 14:38:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 75461 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-23 03:10, Eli Zaretskii wrote:
>> What would you like me to do from here?
>
> I have no idea, it sounds like some issue with the window manager?
> maybe martin (CC'ed) could help.
>
> Do you have a simple enough recipe to reproduce this starting from
> "emacs -Q"?
I don't, but I'll see whether I can figure one out.
One of the triggers is that my email client buffer is displayed,
and I don't know why that's relevant. If I can replicate the bug
with a *copy* of that buffer, though, then I should be able to
narrow down that requirement and put together a recipe.
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sat, 22 Feb 2025 15:52:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 23 Feb 2025 03:37:37 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: martin rudalics <rudalics <at> gmx.at>, 75461 <at> debbugs.gnu.org
>
> On 2025-02-23 03:10, Eli Zaretskii wrote:
> >> What would you like me to do from here?
> >
> > I have no idea, it sounds like some issue with the window manager?
> > maybe martin (CC'ed) could help.
> >
> > Do you have a simple enough recipe to reproduce this starting from
> > "emacs -Q"?
>
> I don't, but I'll see whether I can figure one out.
>
> One of the triggers is that my email client buffer is displayed,
Is that in a GUI frame or a TTY frame?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sat, 22 Feb 2025 16:09:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> I have no idea, it sounds like some issue with the window manager?
> maybe martin (CC'ed) could help.
IIUC the garbage flag of a frame is set over and over again. So I would
first try to put breakpoints on the four SET_FRAME_GARBAGED calls in
xterm.c as soon as you control Emacs from the debugger. This should
tell whether the window manager is causing it. Next I would try the
calls in xdisp.c. Simply lean on the c button in GDB. If the culprit
is there, it should still be there when you release the button after a
while. But wait: Eli might think that this is a silly idea.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sat, 22 Feb 2025 18:09:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 22 Feb 2025 17:08:40 +0100
> Cc: 75461 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > I have no idea, it sounds like some issue with the window manager?
> > maybe martin (CC'ed) could help.
>
> IIUC the garbage flag of a frame is set over and over again. So I would
> first try to put breakpoints on the four SET_FRAME_GARBAGED calls in
> xterm.c as soon as you control Emacs from the debugger. This should
> tell whether the window manager is causing it. Next I would try the
> calls in xdisp.c. Simply lean on the c button in GDB. If the culprit
> is there, it should still be there when you release the button after a
> while. But wait: Eli might think that this is a silly idea.
I don't.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Sun, 23 Feb 2025 13:15:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 75461 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-23 04:51, Eli Zaretskii wrote:
>> One of the triggers is that my email client buffer is displayed,
>
> Is that in a GUI frame or a TTY frame?
In a GUI frame. I haven't managed to reproduce it with a TTY frame.
This far I've failed to figure out a recipe for reproducing this from
emacs -Q, so I'll put those attempts on hold for now, and try Martin's
suggestions next.
Failing anything else, I can try to git-bisect it vs Emacs 29 (where
I didn't experience the problem).
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75461; Package
emacs.
(Mon, 24 Feb 2025 08:56:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 75461 <at> debbugs.gnu.org (full text, mbox):
> Failing anything else, I can try to git-bisect it vs Emacs 29 (where
> I didn't experience the problem).
I think that bisecting will be the simpler way.
martin
This bug report was last modified 109 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.