bug#44448: 27.1; Strange inteference between timer, modeline/header-line and buffer position in window

bug#44448: 27.1; Strange inteference between timer, modeline/header-line and buffer position in window

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 4980 bytes --]

When:

- 2 windows open the same file
- There's a timer dealing with modeline or header-line format

Then pressing `C-g` sometimes scrolls the buffer in this window to the
position in the other window.

Here's a recipe for reproduce:

- `$ emacs -Q`

- Eval this:
  ```
  (run-with-timer 0 0.1 (lambda () (setq mode-line-format "hi")))
  ```

- `M-x delete-other-windows` so we have only one window.

- `C-x C-f` to open a file. I use
  <https://github.com/lsof-org/lsof/blob/master/main.c> when testing,
  but any file that's long enough should work.

- `M-x split-window-horizontally`, so we have 2 windows viewing the same
  file. For some reason, splitting vertically doesn't trigger the
  problem.

- Scroll one window down to somethere.

- Hold `C-g` or press it repeatedly and quickly, then the window will go
  to the same position in file as the other window.

You can do the same with `header-line-format`, it also has the problem.
Using `run-with-idle-timer` instead seems doesn't have the problem.

See also <https://github.com/kiennq/emacs-mini-modeline/issues/45> where
I report the same problem. I believe another package that's influenced
by this is <https://github.com/purcell/mode-line-bell>.

--- Info generated by `report-emacs-bug` ---

In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo version 1.17.3)
 of 2020-08-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Manjaro Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
[nil 24482 55348 93490 0.1 (closure (t) nil (setq mode-line-format "hi"))
nil nil 920000]
You can run the command ‘split-window-horizontally’ with M-x sp-h RET
Quit [22 times]
Quit
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-wide-int
 --with-modules --with-cairo --with-harfbuzz 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MONETARY: zh_CN.UTF-8
  value of $LC_NUMERIC: zh_CN.UTF-8
  value of $LC_TIME: zh_CN.UTF-8
  value of $LANG: zh_CN.utf8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils vc-git diff-mode
easy-mmode cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib china-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic 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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 75931 7519)
 (symbols 48 8992 1)
 (strings 32 23346 1733)
 (string-bytes 1 858985)
 (vectors 16 14047)
 (vector-slots 8 224399 9036)
 (floats 8 27 38)
 (intervals 56 1440 1)
 (buffers 1000 12))

[-- Attachment #2: Type: text/html, Size: 5587 bytes --]

bug#44448: 27.1; Strange inteference between timer, modeline/header-line and buffer position in window

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Thu, 5 Nov 2020 00:48:59 +0800
> 
> When:
> 
> - 2 windows open the same file
> - There's a timer dealing with modeline or header-line format
> 
> Then pressing `C-g` sometimes scrolls the buffer in this window to the
> position in the other window.

Thanks, I hope I fixed this now on the emacs-27 branch.

bug#44448: 27.1; Strange inteference between timer, modeline/header-line and buffer position in window

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Then pressing `C-g` sometimes scrolls the buffer in this window to the
>> position in the other window.
>
> Thanks, I hope I fixed this now on the emacs-27 branch.

There was no response, so I'm closing this bug report.  If the problem
still exists, please respond to this email and we'll reopen the bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 4677 bytes --]

I'm on Emacs 28 now. The problem can still be reproduced, just the
chance becomes lower. Maybe it's appropriate to reopen this.

I've found some factors that seem to increase the chance to reproduce,
so here's a new recipe:

- `$ emacs -Q`

- Eval this:

  (run-with-timer 0 0.01 (lambda () (setq mode-line-format "hi")))

  Smaller `repeat` value seems to increase the chance. Also notice that
  setting `header-line-format` and `tab-line-format` can both work.

- `M-x delete-other-windows` so we have only one window.

- `C-x C-f` to open a file. I use
  https://github.com/lsof-org/lsof/blob/master/main.c when testing, but
  any file that's long enough should work.

- `M-x split-window-horizontally`, so we have 2 windows viewing the same
  file.

- Shrink the Emacs frame until many lines are not fully displayed. This
  is important. It increases the chance by a lot.

- Scroll one window down to somethere.

- Hold `C-g`, then the window will go to the same position in file as
  the other window. If it doesn't, release `C-g` and hold it again.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.17.4)
 of 2021-02-05 built on kino-pc2
Repository revision: 9730575f3a2599be0a4f9c3d1ef5321bf1294e93
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Manjaro Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-modules --without-gconf --without-gsettings
 --enable-link-time-optimization --with-x-toolkit=gtk3 --without-xaw3d
 --without-compress-install 'CFLAGS=-march=x86-64 -mtune=generic -O2
 -pipe -fno-plt -flto -fuse-linker-plugin -flto -fuse-linker-plugin'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: zh_CN.UTF-8
  value of $LC_NUMERIC: zh_CN.UTF-8
  value of $LC_TIME: zh_CN.UTF-8
  value of $LANG: zh_CN.utf8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils vc-git diff-mode easy-mmode
cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs time-date subr-x cl-loaddefs cl-lib china-util
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting font-render-setting cairo move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 85780 7204)
 (symbols 48 9615 1)
 (strings 32 26180 1255)
 (string-bytes 1 967039)
 (vectors 16 16414)
 (vector-slots 8 262420 9066)
 (floats 8 29 56)
 (intervals 56 2112 0)
 (buffers 984 11))

[-- Attachment #2: Type: text/html, Size: 5246 bytes --]

bug#44448:

[Lars Ingebrigtsen]

Amai Kinono <amaikinono@gmail.com> writes:

> I'm on Emacs 28 now. The problem can still be reproduced, just the
> chance becomes lower. Maybe it's appropriate to reopen this.

OK; reopening.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44448:

[Amai Kinono]

[-- Attachment #1.1: Type: text/plain, Size: 1859 bytes --]

My recent test shows this also happens when you modify overlay in the buffer
frequently. Also, a timer is not needed, it happens when it's frequent
enough.

Recipe:

1. emacs -Q

2. Eval this:

(require 'paren)
(add-hook 'post-command-hook
 (lambda ()
   (let ((show-paren-mode t))
     (show-paren-function))))

   It's a setup to run show-paren-function in post-command-hook. Directly
using
   show-paren-mode also cause the bug, but the chance is way lower, as it
   delays the refreshing using a timer. It happens to me occasionally when
I'm
   coding with show-paren-mode on.

3. M-x find-library RET paren

4. M-x split-window-horizontally

5. Move to a position in the left window where there's a bunch of closing
  parens. You should see show-paren-function is highting them for you.

6. Scroll the right window to a position where you can see the matching
opening
   parens. Now show-paren-function should highlight opening parens in the
right
   window, and closing parens in the left window.

7. Go back to the left window. Hold Ctrl and press f/b/g at the same time
   several times (so you are sending C-f, C-b and C-g frequently)

8. The cursor in the left window will jump to the position of the
   right window cursor.

I've attached a gif so you could see it clealy.

At this time, I think the bug occurs when you frequently write text to
header-line, mode-line, minibuffer (see
https://github.com/kiennq/emacs-mini-modeline/issues/45), or operate on
overlays. Using a timer or not doesn't matter.

This has been bugging me for years since company-mode (uses overlay + timer)
also causes this problem. I haven't seen similar bug reports, though. Am I
the
only unlucky company user? Could someone save me from the pain?

Emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.17.4) of 2021-08-11

[-- Attachment #1.2: Type: text/html, Size: 2198 bytes --]

[-- Attachment #2: show-paren-mode-bug.gif --]
[-- Type: image/gif, Size: 112137 bytes --]

bug#44448:

[Lars Ingebrigtsen]

Amai Kinono <amaikinono@gmail.com> writes:

> 7. Go back to the left window. Hold Ctrl and press f/b/g at the same time
>    several times (so you are sending C-f, C-b and C-g frequently)
>
> 8. The cursor in the left window will jump to the position of the
>    right window cursor.

I tried the recipe (in Emacs 27.1), but I was unable to reproduce it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Wed, 11 Aug 2021 13:49:08 +0800
> 
> My recent test shows this also happens when you modify overlay in the buffer
> frequently. Also, a timer is not needed, it happens when it's frequent enough.
> 
> Recipe:
> 
> 1. emacs -Q
> 
> 2. Eval this:
> 
> (require 'paren)
> (add-hook 'post-command-hook
>  (lambda ()
>    (let ((show-paren-mode t))
>      (show-paren-function))))
> 
>    It's a setup to run show-paren-function in post-command-hook. Directly using
>    show-paren-mode also cause the bug, but the chance is way lower, as it
>    delays the refreshing using a timer. It happens to me occasionally when I'm
>    coding with show-paren-mode on.
> 
> 3. M-x find-library RET paren
> 
> 4. M-x split-window-horizontally
> 
> 5. Move to a position in the left window where there's a bunch of closing
>   parens. You should see show-paren-function is highting them for you.
> 
> 6. Scroll the right window to a position where you can see the matching opening
>    parens. Now show-paren-function should highlight opening parens in the right
>    window, and closing parens in the left window.
> 
> 7. Go back to the left window. Hold Ctrl and press f/b/g at the same time
>    several times (so you are sending C-f, C-b and C-g frequently)
> 
> 8. The cursor in the left window will jump to the position of the
>    right window cursor.

Some code in paren.el probably moves point without unwind-protect, or
something like that.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 5212 bytes --]

---------- Forwarded message ---------
发件人： Amai Kinono <amaikinono@gmail.com>
Date: 2021年8月11日周三 下午8:16
Subject: Re: bug#44448:
To: Lars Ingebrigtsen <larsi@gnus.org>


Thanks. I just noticed I haven't offer additional information. I'm on Emacs
28.
Info generated by report-emacs-bug is attached at the bottom.

The issue happens by chance. You have to be lucky (or unlucky) enough to
trigger it. Maybe you could close and reopen Emacs, and try it several more
times? I can't reproduce every time using the same recipe, but I'm lucky
when
recording that gif.

I've asked in a forum if any company user has encountered the same problem
(https://emacs-china.org/t/buffer/18062, in Chinese). Some said they've
never
seen this, some have.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.17.4)
 of 2021-08-11 built on kino-pc2
Repository revision: a8e89964f3553f40b8807617c3b181f42cd22fd9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Manjaro Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-modules --without-gconf --without-gsettings
 --enable-link-time-optimization --with-x-toolkit=gtk3 --without-xaw3d
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -flto -fuse-linker-plugin
 -flto -fuse-linker-plugin'
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: zh_CN.UTF-8
  value of $LC_NUMERIC: zh_CN.UTF-8
  value of $LC_TIME: zh_CN.UTF-8
  value of $LANG: zh_CN.utf8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch seq byte-opt gv bytecomp byte-compile cconv
thingatpt find-func paren time-date subr-x cl-loaddefs cl-lib china-util
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-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 cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting font-render-setting cairo move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 53927 8101)
 (symbols 48 6754 1)
 (strings 32 18875 2050)
 (string-bytes 1 619423)
 (vectors 16 14183)
 (vector-slots 8 234763 10474)
 (floats 8 26 106)
 (intervals 56 602 10)
 (buffers 992 12))

Lars Ingebrigtsen <larsi@gnus.org> 于2021年8月11日周三 下午7:20写道：

    Amai Kinono <amaikinono@gmail.com> writes:

    > 7. Go back to the left window. Hold Ctrl and press f/b/g at the same
time
    >    several times (so you are sending C-f, C-b and C-g frequently)
    >
    > 8. The cursor in the left window will jump to the position of the
    >    right window cursor.

    I tried the recipe (in Emacs 27.1), but I was unable to reproduce it.

    --
    (domestic pets only, the antidote for overdose, milk.)
       bloggy blog: http://lars.ingebrigtsen.no

[-- Attachment #2: Type: text/html, Size: 6139 bytes --]

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1.1: Type: text/plain, Size: 3295 bytes --]

---------- Forwarded message ---------
发件人： Amai Kinono <amaikinono@gmail.com>
Date: 2021年8月11日周三 下午8:16
Subject: Re: bug#44448:
To: Eli Zaretskii <eliz@gnu.org>


> Some code in paren.el probably moves point without unwind-protect, or
something like that.

It's not. To answer you, I've created a new recipe that only moves overlay,
and
triggers the problem:

1. emacs -Q

2. M-x find-library RET paren

3. M-x split-window-horizontally

4. Go to the bottom of the file

5. M-x read-only-mode to turn off read-only-mode so we can write things
here.
   Also M-x auto-save-mode to stop Emacs from auto saving it.

6. Paste and eval this:

(defvar test-overlay (make-overlay (point-min) (1+ (point-min))))
(overlay-put test-overlay 'face 'isearch)
(run-with-timer 0 0.05 (lambda ()
                         (let ((beg (random 5)))
                           (move-overlay test-overlay beg (1+ beg)))))
(defvar test-overlay2 (make-overlay (1- (point-max)) (point-max)))
(overlay-put test-overlay2 'face 'isearch)
(run-with-timer 0 0.05 (lambda ()
                         (let ((beg (- (point-max) (random 5))))
                           (move-overlay test-overlay beg (1+ beg)))))

   Now we have 2 overlays dancing at the beginning and end of buffer.

7. Go to the end of ther buffer, holding C-g for several secs. You may need
to
   do this several times, but there are chances that the cursor goes to the
   beginning of the buffer.

Screen recording attached. For things like system information, see my last
reply to Lars.

Eli Zaretskii <eliz@gnu.org> 于2021年8月11日周三 下午7:43写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Wed, 11 Aug 2021 13:49:08 +0800
> >
> > My recent test shows this also happens when you modify overlay in the
> buffer
> > frequently. Also, a timer is not needed, it happens when it's frequent
> enough.
> >
> > Recipe:
> >
> > 1. emacs -Q
> >
> > 2. Eval this:
> >
> > (require 'paren)
> > (add-hook 'post-command-hook
> >  (lambda ()
> >    (let ((show-paren-mode t))
> >      (show-paren-function))))
> >
> >    It's a setup to run show-paren-function in post-command-hook.
> Directly using
> >    show-paren-mode also cause the bug, but the chance is way lower, as it
> >    delays the refreshing using a timer. It happens to me occasionally
> when I'm
> >    coding with show-paren-mode on.
> >
> > 3. M-x find-library RET paren
> >
> > 4. M-x split-window-horizontally
> >
> > 5. Move to a position in the left window where there's a bunch of closing
> >   parens. You should see show-paren-function is highting them for you.
> >
> > 6. Scroll the right window to a position where you can see the matching
> opening
> >    parens. Now show-paren-function should highlight opening parens in
> the right
> >    window, and closing parens in the left window.
> >
> > 7. Go back to the left window. Hold Ctrl and press f/b/g at the same time
> >    several times (so you are sending C-f, C-b and C-g frequently)
> >
> > 8. The cursor in the left window will jump to the position of the
> >    right window cursor.
>
> Some code in paren.el probably moves point without unwind-protect, or
> something like that.
>

[-- Attachment #1.2: Type: text/html, Size: 4315 bytes --]

[-- Attachment #2: overlay-bug.gif --]
[-- Type: image/gif, Size: 63946 bytes --]

bug#44448: [Amai Kinono] Re: bug#44448:

[Lars Ingebrigtsen]

[-- Attachment #0: Type: message/rfc822, Size: 11582 bytes --]

[-- Attachment #1.1: Type: text/plain, Size: 5013 bytes --]

Thanks. I just noticed I haven't offer additional information. I'm on Emacs
28.
Info generated by report-emacs-bug is attached at the bottom.

The issue happens by chance. You have to be lucky (or unlucky) enough to
trigger it. Maybe you could close and reopen Emacs, and try it several more
times? I can't reproduce every time using the same recipe, but I'm lucky
when
recording that gif.

I've asked in a forum if any company user has encountered the same problem
(https://emacs-china.org/t/buffer/18062, in Chinese). Some said they've
never
seen this, some have.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.17.4)
 of 2021-08-11 built on kino-pc2
Repository revision: a8e89964f3553f40b8807617c3b181f42cd22fd9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Manjaro Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-modules --without-gconf --without-gsettings
 --enable-link-time-optimization --with-x-toolkit=gtk3 --without-xaw3d
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -flto -fuse-linker-plugin
 -flto -fuse-linker-plugin'
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: zh_CN.UTF-8
  value of $LC_NUMERIC: zh_CN.UTF-8
  value of $LC_TIME: zh_CN.UTF-8
  value of $LANG: zh_CN.utf8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch seq byte-opt gv bytecomp byte-compile cconv
thingatpt find-func paren time-date subr-x cl-loaddefs cl-lib china-util
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-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 cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting font-render-setting cairo move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 53927 8101)
 (symbols 48 6754 1)
 (strings 32 18875 2050)
 (string-bytes 1 619423)
 (vectors 16 14183)
 (vector-slots 8 234763 10474)
 (floats 8 26 106)
 (intervals 56 602 10)
 (buffers 992 12))

Lars Ingebrigtsen <larsi@gnus.org> 于2021年8月11日周三 下午7:20写道：

    Amai Kinono <amaikinono@gmail.com> writes:

    > 7. Go back to the left window. Hold Ctrl and press f/b/g at the same
time
    >    several times (so you are sending C-f, C-b and C-g frequently)
    >
    > 8. The cursor in the left window will jump to the position of the
    >    right window cursor.

    I tried the recipe (in Emacs 27.1), but I was unable to reproduce it.

    --
    (domestic pets only, the antidote for overdose, milk.)
       bloggy blog: http://lars.ingebrigtsen.no

[-- Attachment #1.2: Type: text/html, Size: 5603 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Wed, 11 Aug 2021 20:18:36 +0800
> 
> > Some code in paren.el probably moves point without unwind-protect, or
> something like that.
> 
> It's not. To answer you, I've created a new recipe that only moves overlay, and
> triggers the problem:
> 
> 1. emacs -Q
> 
> 2. M-x find-library RET paren
> 
> 3. M-x split-window-horizontally
> 
> 4. Go to the bottom of the file
> 
> 5. M-x read-only-mode to turn off read-only-mode so we can write things here.
>    Also M-x auto-save-mode to stop Emacs from auto saving it.
> 
> 6. Paste and eval this:
> 
> (defvar test-overlay (make-overlay (point-min) (1+ (point-min))))
> (overlay-put test-overlay 'face 'isearch)
> (run-with-timer 0 0.05 (lambda ()
>                          (let ((beg (random 5)))
>                            (move-overlay test-overlay beg (1+ beg)))))
> (defvar test-overlay2 (make-overlay (1- (point-max)) (point-max)))
> (overlay-put test-overlay2 'face 'isearch)
> (run-with-timer 0 0.05 (lambda ()
>                          (let ((beg (- (point-max) (random 5))))
>                            (move-overlay test-overlay beg (1+ beg)))))
> 
>    Now we have 2 overlays dancing at the beginning and end of buffer.
> 
> 7. Go to the end of ther buffer, holding C-g for several secs. You may need to
>    do this several times, but there are chances that the cursor goes to the
>    beginning of the buffer.

Thanks.  I see the cause of it: it's the :eval forms that we execute
when we redisplay the mode line, as part of redisplaying a window.
When more than one window displays the same buffer at different buffer
positions, when Emacs redisplays a non-selected window, it temporarily
moves point to the place where it is displayed in that non-selected
window.  If C-g is processed while those :eval forms run, with the
buffer's point temporarily moved, you will see point in the selected
window "inherit" the position of point from the other window showing
the same buffer.  As evidence, after this happens, you should be able
to see this in *Messages*:

  Error during redisplay: (mode-line-default-help-echo #<window 3 on paren.el>) signaled (quit)

We could prevent this jumping of point in these cases by running the
:eval forms in the mode line with inhibit-quit bound to t, but then it
will be impossible to interrupt :eval forms that run amok for some
reason, which is a real danger, since the mode-line format is very
frequently customized to include more or less arbitrary Lisp.  So I'm
not sure that inhibiting quitting would be a good idea here: the cure
could be worse than the disease.

Ideas for fixing this are welcome.

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> Date: Thu, 12 Aug 2021 15:44:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 44448@debbugs.gnu.org
> 
> Thanks.  I see the cause of it: it's the :eval forms that we execute
> when we redisplay the mode line, as part of redisplaying a window.
> When more than one window displays the same buffer at different buffer
> positions, when Emacs redisplays a non-selected window, it temporarily
> moves point to the place where it is displayed in that non-selected
> window.  If C-g is processed while those :eval forms run, with the
> buffer's point temporarily moved, you will see point in the selected
> window "inherit" the position of point from the other window showing
> the same buffer.  As evidence, after this happens, you should be able
> to see this in *Messages*:
> 
>   Error during redisplay: (mode-line-default-help-echo #<window 3 on paren.el>) signaled (quit)

Actually, that cannot be the whole story.  Because evaluating the
:eval forms in the mode line arranges for catching the errors (and the
above text in *Messages* is the evidence that it works here), and so
we should have still run redisplay_window to completion after that,
which includes restoring the buffer's point to its original value.
Hmm...

bug#44448: Fwd: bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 4158 bytes --]

---------- Forwarded message ---------
发件人： Amai Kinono <amaikinono@gmail.com>
Date: 2021年8月13日周五 下午5:49
Subject: Re: bug#44448: Fwd: bug#44448:
To: Eli Zaretskii <eliz@gnu.org>


Thanks for testing! I feel kind of relieved when I know it can be
reproduced.

> I see the cause of it: it's the :eval forms that we execute
> when we redisplay the mode line, as part of redisplaying a window.

> As evidence, after this happens, you should be able
> to see this in *Messages*:
>
>  Error during redisplay: (mode-line-default-help-echo #<window 3 on
paren.el>) signaled (quit)

I'm afraid this is not the truth. If you eval

    (setq-default mode-line-format nil)

before step 6, the problem still happens, and there's no error messages in
the *Messages* buffer.

When testing with mode-line-format being nil, I noticed that:

- after I pressed C-x b and I'm in the minibuffer,
- occasionally, when I'm visiting *Messages* or *Buffer list* buffer,

The overlay that should appear at the bottom of paren.el moves to its
beginning. The reason looks like (point-max) is returning the maximum point
in current buffer. I don't know if this fact has anything to do with the
bug, though.

Eli Zaretskii <eliz@gnu.org> 于2021年8月12日周四 下午8:44写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Wed, 11 Aug 2021 20:18:36 +0800
> >
> > > Some code in paren.el probably moves point without unwind-protect, or
> > something like that.
> >
> > It's not. To answer you, I've created a new recipe that only moves
> overlay, and
> > triggers the problem:
> >
> > 1. emacs -Q
> >
> > 2. M-x find-library RET paren
> >
> > 3. M-x split-window-horizontally
> >
> > 4. Go to the bottom of the file
> >
> > 5. M-x read-only-mode to turn off read-only-mode so we can write things
> here.
> >    Also M-x auto-save-mode to stop Emacs from auto saving it.
> >
> > 6. Paste and eval this:
> >
> > (defvar test-overlay (make-overlay (point-min) (1+ (point-min))))
> > (overlay-put test-overlay 'face 'isearch)
> > (run-with-timer 0 0.05 (lambda ()
> >                          (let ((beg (random 5)))
> >                            (move-overlay test-overlay beg (1+ beg)))))
> > (defvar test-overlay2 (make-overlay (1- (point-max)) (point-max)))
> > (overlay-put test-overlay2 'face 'isearch)
> > (run-with-timer 0 0.05 (lambda ()
> >                          (let ((beg (- (point-max) (random 5))))
> >                            (move-overlay test-overlay beg (1+ beg)))))
> >
> >    Now we have 2 overlays dancing at the beginning and end of buffer.
> >
> > 7. Go to the end of ther buffer, holding C-g for several secs. You may
> need to
> >    do this several times, but there are chances that the cursor goes to
> the
> >    beginning of the buffer.
>
> Thanks.  I see the cause of it: it's the :eval forms that we execute
> when we redisplay the mode line, as part of redisplaying a window.
> When more than one window displays the same buffer at different buffer
> positions, when Emacs redisplays a non-selected window, it temporarily
> moves point to the place where it is displayed in that non-selected
> window.  If C-g is processed while those :eval forms run, with the
> buffer's point temporarily moved, you will see point in the selected
> window "inherit" the position of point from the other window showing
> the same buffer.  As evidence, after this happens, you should be able
> to see this in *Messages*:
>
>   Error during redisplay: (mode-line-default-help-echo #<window 3 on
> paren.el>) signaled (quit)
>
> We could prevent this jumping of point in these cases by running the
> :eval forms in the mode line with inhibit-quit bound to t, but then it
> will be impossible to interrupt :eval forms that run amok for some
> reason, which is a real danger, since the mode-line format is very
> frequently customized to include more or less arbitrary Lisp.  So I'm
> not sure that inhibiting quitting would be a good idea here: the cure
> could be worse than the disease.
>
> Ideas for fixing this are welcome.
>

[-- Attachment #2: Type: text/html, Size: 5402 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

[Please use Reply All when you reply, to keep the bug address on the
CC list.]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Fri, 13 Aug 2021 17:49:24 +0800
> 
> Thanks for testing! I feel kind of relieved when I know it can be reproduced.
> 
> > I see the cause of it: it's the :eval forms that we execute
> > when we redisplay the mode line, as part of redisplaying a window.
> 
> > As evidence, after this happens, you should be able
> > to see this in *Messages*:
> >
> >  Error during redisplay: (mode-line-default-help-echo #<window 3 on paren.el>) signaled (quit)
> 
> I'm afraid this is not the truth. If you eval
> 
>     (setq-default mode-line-format nil)
> 
> before step 6, the problem still happens, and there's no error messages in the *Messages* buffer.

Not here, it doesn't.  If I set mode-line-format to nil in the buffer
that visits paren.el, I cannot reproduce the problem anymore.

However, as I wrote in my other message, the :eval form in the mode
line cannot be the whole story, because we evaluate these forms in a
way that should (and does) catch any errors, including quit.
Something else is at work here.

P.S. FTR, I use setq, not setq-default, and I also do this before
running the experiment (to avoid unrelated triggers for redisplay):

  M-x blink-cursor-mode RET
  M-x global-eldoc-mode RET

And M-~ after pasting the code which starts the overlays.

> When testing with mode-line-format being nil, I noticed that:
> 
> - after I pressed C-x b and I'm in the minibuffer,
> - occasionally, when I'm visiting *Messages* or *Buffer list* buffer,
> 
> The overlay that should appear at the bottom of paren.el moves to its beginning. The reason looks like
> (point-max) is returning the maximum point in current buffer. I don't know if this fact has anything to do with
> the bug, though.

I'm not sure either, but your timer functions in general don't switch
to the specific buffer, so this could be unrelated.

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> Date: Sat, 14 Aug 2021 12:25:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 44448@debbugs.gnu.org
> 
> > >  Error during redisplay: (mode-line-default-help-echo #<window 3 on paren.el>) signaled (quit)
> > 
> > I'm afraid this is not the truth. If you eval
> > 
> >     (setq-default mode-line-format nil)
> > 
> > before step 6, the problem still happens, and there's no error messages in the *Messages* buffer.
> 
> Not here, it doesn't.  If I set mode-line-format to nil in the buffer
> that visits paren.el, I cannot reproduce the problem anymore.
> 
> However, as I wrote in my other message, the :eval form in the mode
> line cannot be the whole story, because we evaluate these forms in a
> way that should (and does) catch any errors, including quit.
> Something else is at work here.

I found a few places where we allowed redisplay_window to exit
non-locally, leaving point in its temporarily wrong position.  This
should now be fixed on the master branch.  Please test.

Thanks.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

I'm on the latest commit (55772baee1627571c0814cf2d666fb3b963ff591) now.
Unfortunately the bug can still be reproduced on my side.

> FTR, I use setq, not setq-default, and I also do this before
> running the experiment (to avoid unrelated triggers for redisplay):

>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET

> And M-~ after pasting the code which starts the overlays.

Even if I follow these steps when testing, with mode-line-format begin nil,
on
the latest commit, it can still be reproduced.

But I think your patch is doing its work. I did some programming work, and I
feel the chance it happens becomes lower.

Eli Zaretskii <eliz@gnu.org> 于2021年8月15日周日 下午7:21写道：

> > Date: Sat, 14 Aug 2021 12:25:43 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 44448@debbugs.gnu.org
> >
> > > >  Error during redisplay: (mode-line-default-help-echo #<window 3 on
> paren.el>) signaled (quit)
> > >
> > > I'm afraid this is not the truth. If you eval
> > >
> > >     (setq-default mode-line-format nil)
> > >
> > > before step 6, the problem still happens, and there's no error
> messages in the *Messages* buffer.
> >
> > Not here, it doesn't.  If I set mode-line-format to nil in the buffer
> > that visits paren.el, I cannot reproduce the problem anymore.
> >
> > However, as I wrote in my other message, the :eval form in the mode
> > line cannot be the whole story, because we evaluate these forms in a
> > way that should (and does) catch any errors, including quit.
> > Something else is at work here.
>
> I found a few places where we allowed redisplay_window to exit
> non-locally, leaving point in its temporarily wrong position.  This
> should now be fixed on the master branch.  Please test.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Sun, 15 Aug 2021 20:12:26 +0800
> Cc: 44448@debbugs.gnu.org
> 
> I'm on the latest commit (55772baee1627571c0814cf2d666fb3b963ff591) now.
> Unfortunately the bug can still be reproduced on my side.

If you can still reproduce it, show me the backtrace from
signal_or_quit when the buffer is scrolled from EOB to BOB.  That
backtrace should tell us which code still needs to be fixed.

That is, set a breakpoint in signal_or_quit with the following
commands:

  backtrace
  print current_buffer->pt
  continue
  end

then run your recipe and press C-g until you see the problem happen.
Then post the last few backtraces here.

I can no longer reproduce the problem on my system, so I cannot do
this myself.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

I tried and the bug can happen with breakpoint set. Haven't got a backtrace
though.

I have several questions.

1. I am not familiar with GDB. I set the breakpoint by "b signal_or_quit",
is that right?

2. When I reached the breakpoint, "p current_buffer" gives me "No symbol
"current_buffer" in current context." How should I get the point position
in current window?

3. When the bug happens, the cursor doesn't jump before hitting the
breakpoint, but immediately after I continue using "c". Does this seem
right? (I guess so)

Printing the backtrace is so slow that it freezes my desktop for a long
time (and I don't know if that's forever). I need a way to tell if the bug
happens before I print the backtrace (I think that's the 2nd question
above), so I can make sure I am getting the right backtrace and leave my PC
there for a while.

在 2021年8月15日星期日，Eli Zaretskii gnu.org> 写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Sun, 15 Aug 2021 20:12:26 +0800
> > Cc: 44448@debbugs.gnu.org
> >
> > I'm on the latest commit (55772baee1627571c0814cf2d666fb3b963ff591) now.
> > Unfortunately the bug can still be reproduced on my side.
>
> If you can still reproduce it, show me the backtrace from
> signal_or_quit when the buffer is scrolled from EOB to BOB.  That
> backtrace should tell us which code still needs to be fixed.
>
> That is, set a breakpoint in signal_or_quit with the following
> commands:
>
>   backtrace
>   print current_buffer->pt
>   continue
>   end
>
> then run your recipe and press C-g until you see the problem happen.
> Then post the last few backtraces here.
>
> I can no longer reproduce the problem on my system, so I cannot do
> this myself.
>

[-- Attachment #2: Type: text/html, Size: 2277 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Mon, 16 Aug 2021 02:10:33 +0800
> Cc: "44448@debbugs.gnu.org" <44448@debbugs.gnu.org>
> 
> I tried and the bug can happen with breakpoint set. Haven't got a backtrace though.
> 
> I have several questions.
> 
> 1. I am not familiar with GDB. I set the breakpoint by "b signal_or_quit", is that right?

Yes.

> 2. When I reached the breakpoint, "p current_buffer" gives me "No symbol "current_buffer" in current
> context." How should I get the point position in current window?

I don't understand how this could happen.  current_buffer is a global
variable, it should be visible everywhere.  Is your Emacs built with
the -g3 switch (i.e. CFLAGS includes -g3)?  If not, please rebuild
with CFLAGS=-g3.

> 3. When the bug happens, the cursor doesn't jump before hitting the breakpoint, but immediately after I
> continue using "c". Does this seem right? (I guess so)

Yes.  But you should define commands for the breakpoint, so that Emacs
keeps running.  Like this:

  (gdb) break signal_or_quit
  (gdb) commands
    > backtrace
    > print current_buffer->pt
    > continue
    > end

> Printing the backtrace is so slow that it freezes my desktop for a long time (and I don't know if that's
> forever). I need a way to tell if the bug happens before I print the backtrace (I think that's the 2nd question
> above), so I can make sure I am getting the right backtrace and leave my PC there for a while.

I don't know how to tell that.  In my testing, I kept typing C-g until
I saw the buffer displayed at BOB, then stopped typing C-g and looked
at the last few (2 to 4) backtraces.  I think the backtraces that are
interesting are inside redisplay (under the function
redisplay_internal).

Printing backtrace should be fast enough, it definitely shouldn't
freeze anything.  It didn't freeze for me here.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 5770 bytes --]

Thanks for your help. I've got a backtrace when the bug happens ;)

(The story is, there must be some problems of the developing toolchain on my
distro (tested on 2 PCs running it), so I burn a new ubuntu live CD and
built &
debugged Emacs on it, works like a charm.)

The backtrace:

---

Thread 1 "emacs" hit Breakpoint 3, signal_or_quit
(error_symbol=XIL(0x555555e9b520), data=XIL(0xbee0), keyboard_quit=false)
at eval.c:1793
1793 {
#0  signal_or_quit (error_symbol=XIL(0x555555e9b520), data=XIL(0xbee0),
keyboard_quit=false) at eval.c:1793
#1  0x000055555582d7ad in quit () at eval.c:1783
#2  0x000055555582d68b in process_quit_flag () at eval.c:1730
#3  0x000055555582d6d7 in maybe_quit () at eval.c:1750
#4  0x0000555555839e4a in list_length (list=XIL(0)) at fns.c:150
#5  0x000055555590036e in get_logical_fringe_bitmap (w=0x5555567d5870,
bitmap=XIL(0xe430), right_p=1, partial_p=0) at fringe.c:746
#6  0x0000555555903a0b in update_window_fringes (w=0x5555567d5870,
keep_current_p=true) at fringe.c:1248
#7  0x000055555560a033 in redisplay_window (window=XIL(0x5555567d5875),
just_this_one_p=false) at xdisp.c:19401
#8  0x00005555555feaea in redisplay_window_0 (window=XIL(0x5555567d5875))
at xdisp.c:16617
#9  0x000055555582ce52 in internal_condition_case_1 (bfun=0x5555555feaa4
<redisplay_window_0>, arg=XIL(0x5555567d5875),
handlers=XIL(0x7ffff4f39aeb), hfun=0x5555555fea68 <redisplay_window_error>)
at eval.c:1502
#10 0x00005555555fea39 in redisplay_windows (window=XIL(0x5555567d5875)) at
xdisp.c:16597
#11 0x00005555555fe9eb in redisplay_windows (window=XIL(0x55555626ae75)) at
xdisp.c:16591
#12 0x00005555555fd36d in redisplay_internal () at xdisp.c:16065
#13 0x00005555555fe1af in redisplay_preserve_echo_area (from_where=8) at
xdisp.c:16414
#14 0x000055555576221f in detect_input_pending_run_timers (do_display=true)
at keyboard.c:10392
#15 0x00005555558a5422 in wait_reading_process_output (time_limit=30,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0,
just_wait_proc=0) at process.c:5664
#16 0x00005555555ab5b3 in sit_for (timeout=make_fixnum(30), reading=true,
display_option=1) at dispnew.c:6159
#17 0x000055555574d2e1 in read_char (commandflag=1,
map=XIL(0x5555564f7463), prev_event=XIL(0), used_mouse_menu=0x7fffffffd9fd,
end_time=0x0) at keyboard.c:2784
#18 0x0000555555760119 in read_key_sequence (keybuf=0x7fffffffdbe0,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9569
#19 0x0000555555748958 in command_loop_1 () at keyboard.c:1376
#20 0x000055555582cd6f in internal_condition_case (bfun=0x5555557484ba
<command_loop_1>, handlers=XIL(0x90), hfun=0x555555747906 <cmd_error>) at
eval.c:1478
#21 0x000055555574807b in command_loop_2 (handlers=XIL(0x90)) at
keyboard.c:1117
#22 0x000055555582be66 in internal_catch (tag=XIL(0xe280),
func=0x555555748050 <command_loop_2>, arg=XIL(0x90)) at eval.c:1198
#23 0x000055555574801b in command_loop () at keyboard.c:1095
#24 0x00005555557473b1 in recursive_edit_1 () at keyboard.c:720
#25 0x00005555557475cd in Frecursive_edit () at keyboard.c:792
#26 0x0000555555743179 in main (argc=1, argv=0x7fffffffe068) at emacs.c:2310

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
$59 = 1

---

1. I've recorded several backtraces when the bug happens. They look
basically
   the same so I just post one here. To me the update_window_fringes looks
   suspicious.

2. I tested with mode-line-format being nil or the default value, the
backtrace
   when bug happens look the same, so I believe you've fixed the modeline
part.

Eli Zaretskii <eliz@gnu.org> 于2021年8月16日周一 上午2:29写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Mon, 16 Aug 2021 02:10:33 +0800
> > Cc: "44448@debbugs.gnu.org" <44448@debbugs.gnu.org>
> >
> > I tried and the bug can happen with breakpoint set. Haven't got a
> backtrace though.
> >
> > I have several questions.
> >
> > 1. I am not familiar with GDB. I set the breakpoint by "b
> signal_or_quit", is that right?
>
> Yes.
>
> > 2. When I reached the breakpoint, "p current_buffer" gives me "No symbol
> "current_buffer" in current
> > context." How should I get the point position in current window?
>
> I don't understand how this could happen.  current_buffer is a global
> variable, it should be visible everywhere.  Is your Emacs built with
> the -g3 switch (i.e. CFLAGS includes -g3)?  If not, please rebuild
> with CFLAGS=-g3.
>
> > 3. When the bug happens, the cursor doesn't jump before hitting the
> breakpoint, but immediately after I
> > continue using "c". Does this seem right? (I guess so)
>
> Yes.  But you should define commands for the breakpoint, so that Emacs
> keeps running.  Like this:
>
>   (gdb) break signal_or_quit
>   (gdb) commands
>     > backtrace
>     > print current_buffer->pt
>     > continue
>     > end
>
> > Printing the backtrace is so slow that it freezes my desktop for a long
> time (and I don't know if that's
> > forever). I need a way to tell if the bug happens before I print the
> backtrace (I think that's the 2nd question
> > above), so I can make sure I am getting the right backtrace and leave my
> PC there for a while.
>
> I don't know how to tell that.  In my testing, I kept typing C-g until
> I saw the buffer displayed at BOB, then stopped typing C-g and looked
> at the last few (2 to 4) backtraces.  I think the backtraces that are
> interesting are inside redisplay (under the function
> redisplay_internal).
>
> Printing backtrace should be fast enough, it definitely shouldn't
> freeze anything.  It didn't freeze for me here.
>

[-- Attachment #2: Type: text/html, Size: 6640 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Tue, 17 Aug 2021 02:28:45 +0800
> Cc: 44448@debbugs.gnu.org
> 
> Thanks for your help. I've got a backtrace when the bug happens ;)
> 
> (The story is, there must be some problems of the developing toolchain on my
> distro (tested on 2 PCs running it), so I burn a new ubuntu live CD and built &
> debugged Emacs on it, works like a charm.)
> 
> The backtrace:
> 
> ---
> 
> Thread 1 "emacs" hit Breakpoint 3, signal_or_quit (error_symbol=XIL(0x555555e9b520), data=XIL(0xbee0),
> keyboard_quit=false) at eval.c:1793
> 1793 {
> #0  signal_or_quit (error_symbol=XIL(0x555555e9b520), data=XIL(0xbee0), keyboard_quit=false) at
> eval.c:1793
> #1  0x000055555582d7ad in quit () at eval.c:1783
> #2  0x000055555582d68b in process_quit_flag () at eval.c:1730
> #3  0x000055555582d6d7 in maybe_quit () at eval.c:1750
> #4  0x0000555555839e4a in list_length (list=XIL(0)) at fns.c:150
> #5  0x000055555590036e in get_logical_fringe_bitmap (w=0x5555567d5870, bitmap=XIL(0xe430),
> right_p=1, partial_p=0) at fringe.c:746
> #6  0x0000555555903a0b in update_window_fringes (w=0x5555567d5870, keep_current_p=true) at
> fringe.c:1248
> #7  0x000055555560a033 in redisplay_window (window=XIL(0x5555567d5875), just_this_one_p=false) at
> xdisp.c:19401

Thanks, I installed a fix.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 6336 bytes --]

Thanks! Now all the recipes in this thread doesn't trigger the problem.

However, I still encountered it when using Emacs with my own config. It's
basically the same as the show-paren-mode recipe here.

I'm doing this with show-paren-mode:

```
(define-advice show-paren-function (:around (fn) fix)
    "Highlight enclosing parens when point is inside them."
    ;; Hack.  `show-paren-function' checks the value of `show-paren-mode',
but
    ;; we don't want to use `show-paren-mode'.
    (let ((show-paren-mode t))
      (if (looking-at-p (rx (* white) (syntax open-parenthesis)))
          (funcall fn)
        (save-excursion
          (ignore-errors (backward-up-list))
          (funcall fn)))))

(setq
 show-paren-when-point-in-periphery t
 show-paren-when-point-inside-paren t)

(add-hook 'post-command-hook #'show-paren-function)
```

I'm in paren.el, point 11567. Another window is in the same file, point
11524. They are a pair of parens:

```
(overlay-put show-paren--overlay 'face face))))))
^11524                                     ^11567
```

When I press Ctrl+f+g+b, the point jumps back to 11524. Here's the
backtrace:

```
Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=...,
data=..., keyboard_quit=false) at eval.c:1793
1793 {
#0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
eval.c:1793
#1  0x000056215e7d87ad in quit () at eval.c:1783
#2  0x000056215e7d868b in process_quit_flag () at eval.c:1730
#3  0x000056215e7d86d7 in maybe_quit () at eval.c:1750
#4  0x000056215e7eae6f in Fdelq (elt=..., list=...) at fns.c:1841
#5  0x000056215e7fbb95 in font_put_extra (font=..., prop=..., val=...) at
font.c:745
#6  0x000056215e8042a5 in font_clear_prop (attrs=0x7ffd696120e0,
prop=FONT_SLANT_INDEX) at font.c:3114
#7  0x000056215e683b71 in merge_face_vectors (w=0x562161abb2c8,
f=0x562160c3ca78, from=0x7ffd69611cb0, to=0x7ffd696120e0,
named_merge_points=0x7ffd69611c90) at xfaces.c:2234
#8  0x000056215e6841fb in merge_named_face (w=0x562161abb2c8,
f=0x562160c3ca78, face_name=..., to=0x7ffd696120e0,
named_merge_points=0x7ffd69611c90, attr_filter=0) at xfaces.c:2350
#9  0x000056215e685b4e in merge_face_ref (w=0x562161abb2c8,
f=0x562160c3ca78, face_ref=..., to=0x7ffd696120e0, err_msgs=true,
named_merge_points=0x0, attr_filter=0) at xfaces.c:2834
#10 0x000056215e6908b2 in face_at_buffer_position (w=0x562161abb2c8,
pos=11394, endptr=0x7ffd696121e0, limit=11494, mouse=false, base_face_id=0,
attr_filter=0) at xfaces.c:6441
#11 0x000056215e583e8e in face_at_pos (it=0x7ffd69613900, attr_filter=0) at
xdisp.c:4379
#12 0x000056215e584177 in handle_face_prop (it=0x7ffd69613900) at
xdisp.c:4475
#13 0x000056215e582423 in handle_stop (it=0x7ffd69613900) at xdisp.c:3854
#14 0x000056215e592956 in next_element_from_buffer (it=0x7ffd69613900) at
xdisp.c:8905
#15 0x000056215e58ea69 in get_next_display_element (it=0x7ffd69613900) at
xdisp.c:7494
#16 0x000056215e5c590d in display_line (it=0x7ffd69613900, cursor_vpos=17)
at xdisp.c:23588
#17 0x000056215e5b5c7e in try_window (window=..., pos=..., flags=1) at
xdisp.c:19499
#18 0x000056215e5b2859 in redisplay_window (window=...,
just_this_one_p=false) at xdisp.c:18906
#19 0x000056215e5a9aea in redisplay_window_0 (window=...) at xdisp.c:16617
#20 0x000056215e7d7e52 in internal_condition_case_1 (bfun=0x56215e5a9aa4
<redisplay_window_0>, arg=..., handlers=..., hfun=0x56215e5a9a68
<redisplay_window_error>) at eval.c:1502
#21 0x000056215e5a9a39 in redisplay_windows (window=...) at xdisp.c:16597
#22 0x000056215e5a99eb in redisplay_windows (window=...) at xdisp.c:16591
#23 0x000056215e5a836d in redisplay_internal () at xdisp.c:16065
#24 0x000056215e5a5d0e in redisplay () at xdisp.c:15281
#25 0x000056215e6f7707 in read_char (commandflag=1, map=...,
prev_event=..., used_mouse_menu=0x7ffd69618ccd, end_time=0x0) at
keyboard.c:2539
#26 0x000056215e70b119 in read_key_sequence (keybuf=0x7ffd69618eb0,
prompt=..., dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9569
#27 0x000056215e6f3958 in command_loop_1 () at keyboard.c:1376
#28 0x000056215e7d7d6f in internal_condition_case (bfun=0x56215e6f34ba
<command_loop_1>, handlers=..., hfun=0x56215e6f2906 <cmd_error>) at
eval.c:1478
#29 0x000056215e6f307b in command_loop_2 (handlers=...) at keyboard.c:1117
#30 0x000056215e7d6e66 in internal_catch (tag=..., func=0x56215e6f3050
<command_loop_2>, arg=...) at eval.c:1198
#31 0x000056215e6f301b in command_loop () at keyboard.c:1095
#32 0x000056215e6f23b1 in recursive_edit_1 () at keyboard.c:720
#33 0x000056215e6f25cd in Frecursive_edit () at keyboard.c:792
#34 0x000056215e6ee179 in main (argc=1, argv=0x7ffd69619338) at emacs.c:2310
$21 = 11524
```

Eli Zaretskii <eliz@gnu.org> 于2021年8月17日周二 上午3:09写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Tue, 17 Aug 2021 02:28:45 +0800
> > Cc: 44448@debbugs.gnu.org
> >
> > Thanks for your help. I've got a backtrace when the bug happens ;)
> >
> > (The story is, there must be some problems of the developing toolchain
> on my
> > distro (tested on 2 PCs running it), so I burn a new ubuntu live CD and
> built &
> > debugged Emacs on it, works like a charm.)
> >
> > The backtrace:
> >
> > ---
> >
> > Thread 1 "emacs" hit Breakpoint 3, signal_or_quit
> (error_symbol=XIL(0x555555e9b520), data=XIL(0xbee0),
> > keyboard_quit=false) at eval.c:1793
> > 1793 {
> > #0  signal_or_quit (error_symbol=XIL(0x555555e9b520), data=XIL(0xbee0),
> keyboard_quit=false) at
> > eval.c:1793
> > #1  0x000055555582d7ad in quit () at eval.c:1783
> > #2  0x000055555582d68b in process_quit_flag () at eval.c:1730
> > #3  0x000055555582d6d7 in maybe_quit () at eval.c:1750
> > #4  0x0000555555839e4a in list_length (list=XIL(0)) at fns.c:150
> > #5  0x000055555590036e in get_logical_fringe_bitmap (w=0x5555567d5870,
> bitmap=XIL(0xe430),
> > right_p=1, partial_p=0) at fringe.c:746
> > #6  0x0000555555903a0b in update_window_fringes (w=0x5555567d5870,
> keep_current_p=true) at
> > fringe.c:1248
> > #7  0x000055555560a033 in redisplay_window (window=XIL(0x5555567d5875),
> just_this_one_p=false) at
> > xdisp.c:19401
>
> Thanks, I installed a fix.
>

[-- Attachment #2: Type: text/html, Size: 7164 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Wed, 18 Aug 2021 02:09:14 +0800
> Cc: 44448@debbugs.gnu.org
> 
> When I press Ctrl+f+g+b, the point jumps back to 11524. Here's the backtrace:
> 
> ```
> Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
> eval.c:1793
> 1793 {
> #0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at eval.c:1793
> #1  0x000056215e7d87ad in quit () at eval.c:1783
> #2  0x000056215e7d868b in process_quit_flag () at eval.c:1730
> #3  0x000056215e7d86d7 in maybe_quit () at eval.c:1750
> #4  0x000056215e7eae6f in Fdelq (elt=..., list=...) at fns.c:1841
> #5  0x000056215e7fbb95 in font_put_extra (font=..., prop=..., val=...) at font.c:745
> #6  0x000056215e8042a5 in font_clear_prop (attrs=0x7ffd696120e0, prop=FONT_SLANT_INDEX) at
> font.c:3114
> #7  0x000056215e683b71 in merge_face_vectors (w=0x562161abb2c8, f=0x562160c3ca78,
> from=0x7ffd69611cb0, to=0x7ffd696120e0, named_merge_points=0x7ffd69611c90) at xfaces.c:2234
> #8  0x000056215e6841fb in merge_named_face (w=0x562161abb2c8, f=0x562160c3ca78, face_name=...,
> to=0x7ffd696120e0, named_merge_points=0x7ffd69611c90, attr_filter=0) at xfaces.c:2350
> #9  0x000056215e685b4e in merge_face_ref (w=0x562161abb2c8, f=0x562160c3ca78, face_ref=...,
> to=0x7ffd696120e0, err_msgs=true, named_merge_points=0x0, attr_filter=0) at xfaces.c:2834
> #10 0x000056215e6908b2 in face_at_buffer_position (w=0x562161abb2c8, pos=11394,
> endptr=0x7ffd696121e0, limit=11494, mouse=false, base_face_id=0, attr_filter=0) at xfaces.c:6441
> #11 0x000056215e583e8e in face_at_pos (it=0x7ffd69613900, attr_filter=0) at xdisp.c:4379
> #12 0x000056215e584177 in handle_face_prop (it=0x7ffd69613900) at xdisp.c:4475
> #13 0x000056215e582423 in handle_stop (it=0x7ffd69613900) at xdisp.c:3854
> #14 0x000056215e592956 in next_element_from_buffer (it=0x7ffd69613900) at xdisp.c:8905
> #15 0x000056215e58ea69 in get_next_display_element (it=0x7ffd69613900) at xdisp.c:7494
> #16 0x000056215e5c590d in display_line (it=0x7ffd69613900, cursor_vpos=17) at xdisp.c:23588
> #17 0x000056215e5b5c7e in try_window (window=..., pos=..., flags=1) at xdisp.c:19499
> #18 0x000056215e5b2859 in redisplay_window (window=..., just_this_one_p=false) at xdisp.c:18906

Thanks, I installed another fix for this.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 7190 bytes --]

Thanks. Now the chance of the bug becomes very low, but I managed to get
another backtrace. I think we are close to the end.

Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=...,
data=..., keyboard_quit=false) at eval.c:1793
1793 {
#0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
eval.c:1793
#1  0x0000560d8c635853 in quit () at eval.c:1783
#2  0x0000560d8c635731 in process_quit_flag () at eval.c:1730
#3  0x0000560d8c63577d in maybe_quit () at eval.c:1750
#4  0x0000560d8c64aff7 in internal_equal (o1=..., o2=...,
equal_kind=EQUAL_PLAIN, depth=0, ht=...) at fns.c:2591
#5  0x0000560d8c64a8e6 in Fequal (o1=..., o2=...) at fns.c:2500
#6  0x0000560d8c711c0d in search_image_cache (f=0x560d8d870a78, spec=...,
hash=4330934697943008934, foreground=15457202, background=1908769,
font_size=20, font_family=0x560d8d81e1e8 "DejaVu Sans Mono",
ignore_colors=false) at image.c:1623
#7  0x0000560d8c713b6a in lookup_image (f=0x560d8d870a78, spec=...,
face_id=18) at image.c:2450
#8  0x0000560d8c3e60ea in handle_single_display_spec (it=0x7ffeb78b4820,
spec=..., object=..., overlay=..., position=0x7ffeb78b4970, bufpos=0,
display_replaced=0, frame_window_p=true, enable_eval_p=true) at xdisp.c:5791
#9  0x0000560d8c3e380f in handle_display_spec (it=0x7ffeb78b4820, spec=...,
object=..., overlay=..., position=0x7ffeb78b4970, bufpos=0,
frame_window_p=true) at xdisp.c:5278
#10 0x0000560d8c3e3001 in handle_display_prop (it=0x7ffeb78b4820) at
xdisp.c:5187
#11 0x0000560d8c3df423 in handle_stop (it=0x7ffeb78b4820) at xdisp.c:3854
#12 0x0000560d8c3ee685 in next_element_from_string (it=0x7ffeb78b4820) at
xdisp.c:8524
#13 0x0000560d8c3ebab6 in get_next_display_element (it=0x7ffeb78b4820) at
xdisp.c:7500
#14 0x0000560d8c42f88f in display_string (string=0x0, lisp_string=...,
face_string=..., face_string_pos=0, start=0, it=0x7ffeb78b4820,
field_width=0, precision=11, max_x=300, multibyte=0) at xdisp.c:27323
#15 0x0000560d8c42bd6d in display_mode_element (it=0x7ffeb78b4820, depth=4,
field_width=-23, precision=-23, elt=..., props=..., risky=false) at
xdisp.c:25901
#16 0x0000560d8c42cbe1 in display_mode_element (it=0x7ffeb78b4820, depth=3,
field_width=0, precision=0, elt=..., props=..., risky=false) at
xdisp.c:26149
#17 0x0000560d8c42cbe1 in display_mode_element (it=0x7ffeb78b4820, depth=2,
field_width=0, precision=0, elt=..., props=..., risky=false) at
xdisp.c:26149
#18 0x0000560d8c42c59b in display_mode_element (it=0x7ffeb78b4820, depth=1,
field_width=0, precision=0, elt=..., props=..., risky=false) at
xdisp.c:26072
#19 0x0000560d8c42aab6 in display_mode_line (w=0x560d8e5cf430,
face_id=TAB_LINE_FACE_ID, format=...) at xdisp.c:25585
#20 0x0000560d8c3d3123 in pos_visible_p (w=0x560d8e5cf430, charpos=11524,
x=0x7ffeb78ba904, y=0x7ffeb78ba908, rtop=0x7ffeb78ba948,
rbot=0x7ffeb78ba950, rowh=0x7ffeb78ba90c, vpos=0x7ffeb78ba910) at
xdisp.c:1697
#21 0x0000560d8c40f746 in redisplay_window (window=...,
just_this_one_p=false) at xdisp.c:18882
#22 0x0000560d8c406b37 in redisplay_window_0 (window=...) at xdisp.c:16623
#23 0x0000560d8c634ef8 in internal_condition_case_1 (bfun=0x560d8c406af1
<redisplay_window_0>, arg=..., handlers=..., hfun=0x560d8c406ab5
<redisplay_window_error>) at eval.c:1502
#24 0x0000560d8c406a86 in redisplay_windows (window=...) at xdisp.c:16603
#25 0x0000560d8c406a38 in redisplay_windows (window=...) at xdisp.c:16597
#26 0x0000560d8c4053ba in redisplay_internal () at xdisp.c:16071
#27 0x0000560d8c402d5b in redisplay () at xdisp.c:15287
#28 0x0000560d8c5547ad in read_char (commandflag=1, map=...,
prev_event=..., used_mouse_menu=0x7ffeb78be96d, end_time=0x0) at
keyboard.c:2539
#29 0x0000560d8c5681bf in read_key_sequence (keybuf=0x7ffeb78beb50,
prompt=..., dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9569
#30 0x0000560d8c5509fe in command_loop_1 () at keyboard.c:1376
#31 0x0000560d8c634e15 in internal_condition_case (bfun=0x560d8c550560
<command_loop_1>, handlers=..., hfun=0x560d8c54f9ac <cmd_error>) at
eval.c:1478
#32 0x0000560d8c550121 in command_loop_2 (handlers=...) at keyboard.c:1117
#33 0x0000560d8c633f0c in internal_catch (tag=..., func=0x560d8c5500f6
<command_loop_2>, arg=...) at eval.c:1198
#34 0x0000560d8c5500c1 in command_loop () at keyboard.c:1095
#35 0x0000560d8c54f457 in recursive_edit_1 () at keyboard.c:720
#36 0x0000560d8c54f673 in Frecursive_edit () at keyboard.c:792
#37 0x0000560d8c54b21f in main (argc=1, argv=0x7ffeb78befd8) at emacs.c:2310
$61 = 11524

Eli Zaretskii <eliz@gnu.org> 于2021年8月18日周三 上午2:31写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Wed, 18 Aug 2021 02:09:14 +0800
> > Cc: 44448@debbugs.gnu.org
> >
> > When I press Ctrl+f+g+b, the point jumps back to 11524. Here's the
> backtrace:
> >
> > ```
> > Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=...,
> data=..., keyboard_quit=false) at
> > eval.c:1793
> > 1793 {
> > #0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
> eval.c:1793
> > #1  0x000056215e7d87ad in quit () at eval.c:1783
> > #2  0x000056215e7d868b in process_quit_flag () at eval.c:1730
> > #3  0x000056215e7d86d7 in maybe_quit () at eval.c:1750
> > #4  0x000056215e7eae6f in Fdelq (elt=..., list=...) at fns.c:1841
> > #5  0x000056215e7fbb95 in font_put_extra (font=..., prop=..., val=...)
> at font.c:745
> > #6  0x000056215e8042a5 in font_clear_prop (attrs=0x7ffd696120e0,
> prop=FONT_SLANT_INDEX) at
> > font.c:3114
> > #7  0x000056215e683b71 in merge_face_vectors (w=0x562161abb2c8,
> f=0x562160c3ca78,
> > from=0x7ffd69611cb0, to=0x7ffd696120e0,
> named_merge_points=0x7ffd69611c90) at xfaces.c:2234
> > #8  0x000056215e6841fb in merge_named_face (w=0x562161abb2c8,
> f=0x562160c3ca78, face_name=...,
> > to=0x7ffd696120e0, named_merge_points=0x7ffd69611c90, attr_filter=0) at
> xfaces.c:2350
> > #9  0x000056215e685b4e in merge_face_ref (w=0x562161abb2c8,
> f=0x562160c3ca78, face_ref=...,
> > to=0x7ffd696120e0, err_msgs=true, named_merge_points=0x0, attr_filter=0)
> at xfaces.c:2834
> > #10 0x000056215e6908b2 in face_at_buffer_position (w=0x562161abb2c8,
> pos=11394,
> > endptr=0x7ffd696121e0, limit=11494, mouse=false, base_face_id=0,
> attr_filter=0) at xfaces.c:6441
> > #11 0x000056215e583e8e in face_at_pos (it=0x7ffd69613900, attr_filter=0)
> at xdisp.c:4379
> > #12 0x000056215e584177 in handle_face_prop (it=0x7ffd69613900) at
> xdisp.c:4475
> > #13 0x000056215e582423 in handle_stop (it=0x7ffd69613900) at xdisp.c:3854
> > #14 0x000056215e592956 in next_element_from_buffer (it=0x7ffd69613900)
> at xdisp.c:8905
> > #15 0x000056215e58ea69 in get_next_display_element (it=0x7ffd69613900)
> at xdisp.c:7494
> > #16 0x000056215e5c590d in display_line (it=0x7ffd69613900,
> cursor_vpos=17) at xdisp.c:23588
> > #17 0x000056215e5b5c7e in try_window (window=..., pos=..., flags=1) at
> xdisp.c:19499
> > #18 0x000056215e5b2859 in redisplay_window (window=...,
> just_this_one_p=false) at xdisp.c:18906
>
> Thanks, I installed another fix for this.
>

[-- Attachment #2: Type: text/html, Size: 7857 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Wed, 18 Aug 2021 20:05:10 +0800
> Cc: 44448@debbugs.gnu.org
> 
> Thanks. Now the chance of the bug becomes very low, but I managed to get another backtrace. I think we
> are close to the end.
> 
> Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
> eval.c:1793
> 1793 {
> #0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at eval.c:1793
> #1  0x0000560d8c635853 in quit () at eval.c:1783
> #2  0x0000560d8c635731 in process_quit_flag () at eval.c:1730
> #3  0x0000560d8c63577d in maybe_quit () at eval.c:1750
> #4  0x0000560d8c64aff7 in internal_equal (o1=..., o2=..., equal_kind=EQUAL_PLAIN, depth=0, ht=...) at
> fns.c:2591
> #5  0x0000560d8c64a8e6 in Fequal (o1=..., o2=...) at fns.c:2500
> #6  0x0000560d8c711c0d in search_image_cache (f=0x560d8d870a78, spec=...,
> hash=4330934697943008934, foreground=15457202, background=1908769, font_size=20,
> font_family=0x560d8d81e1e8 "DejaVu Sans Mono", ignore_colors=false) at image.c:1623
> #7  0x0000560d8c713b6a in lookup_image (f=0x560d8d870a78, spec=..., face_id=18) at image.c:2450
> #8  0x0000560d8c3e60ea in handle_single_display_spec (it=0x7ffeb78b4820, spec=..., object=...,
> overlay=..., position=0x7ffeb78b4970, bufpos=0, display_replaced=0, frame_window_p=true,
> enable_eval_p=true) at xdisp.c:5791
> #9  0x0000560d8c3e380f in handle_display_spec (it=0x7ffeb78b4820, spec=..., object=..., overlay=...,
> position=0x7ffeb78b4970, bufpos=0, frame_window_p=true) at xdisp.c:5278
> #10 0x0000560d8c3e3001 in handle_display_prop (it=0x7ffeb78b4820) at xdisp.c:5187
> #11 0x0000560d8c3df423 in handle_stop (it=0x7ffeb78b4820) at xdisp.c:3854
> #12 0x0000560d8c3ee685 in next_element_from_string (it=0x7ffeb78b4820) at xdisp.c:8524
> #13 0x0000560d8c3ebab6 in get_next_display_element (it=0x7ffeb78b4820) at xdisp.c:7500
> #14 0x0000560d8c42f88f in display_string (string=0x0, lisp_string=..., face_string=..., face_string_pos=0,
> start=0, it=0x7ffeb78b4820, field_width=0, precision=11, max_x=300, multibyte=0) at xdisp.c:27323
> #15 0x0000560d8c42bd6d in display_mode_element (it=0x7ffeb78b4820, depth=4, field_width=-23,
> precision=-23, elt=..., props=..., risky=false) at xdisp.c:25901

Thanks, plugged this one.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

Thanks! From what I can tell, the bug is gone. I've been programming in
Emacs for a while and haven't encountered it.

Thank you so, so much, Eli!

Eli Zaretskii <eliz@gnu.org> 于2021年8月18日周三 下午9:16写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Wed, 18 Aug 2021 20:05:10 +0800
> > Cc: 44448@debbugs.gnu.org
> >
> > Thanks. Now the chance of the bug becomes very low, but I managed to get
> another backtrace. I think we
> > are close to the end.
> >
> > Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=...,
> data=..., keyboard_quit=false) at
> > eval.c:1793
> > 1793 {
> > #0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
> eval.c:1793
> > #1  0x0000560d8c635853 in quit () at eval.c:1783
> > #2  0x0000560d8c635731 in process_quit_flag () at eval.c:1730
> > #3  0x0000560d8c63577d in maybe_quit () at eval.c:1750
> > #4  0x0000560d8c64aff7 in internal_equal (o1=..., o2=...,
> equal_kind=EQUAL_PLAIN, depth=0, ht=...) at
> > fns.c:2591
> > #5  0x0000560d8c64a8e6 in Fequal (o1=..., o2=...) at fns.c:2500
> > #6  0x0000560d8c711c0d in search_image_cache (f=0x560d8d870a78, spec=...,
> > hash=4330934697943008934, foreground=15457202, background=1908769,
> font_size=20,
> > font_family=0x560d8d81e1e8 "DejaVu Sans Mono", ignore_colors=false) at
> image.c:1623
> > #7  0x0000560d8c713b6a in lookup_image (f=0x560d8d870a78, spec=...,
> face_id=18) at image.c:2450
> > #8  0x0000560d8c3e60ea in handle_single_display_spec (it=0x7ffeb78b4820,
> spec=..., object=...,
> > overlay=..., position=0x7ffeb78b4970, bufpos=0, display_replaced=0,
> frame_window_p=true,
> > enable_eval_p=true) at xdisp.c:5791
> > #9  0x0000560d8c3e380f in handle_display_spec (it=0x7ffeb78b4820,
> spec=..., object=..., overlay=...,
> > position=0x7ffeb78b4970, bufpos=0, frame_window_p=true) at xdisp.c:5278
> > #10 0x0000560d8c3e3001 in handle_display_prop (it=0x7ffeb78b4820) at
> xdisp.c:5187
> > #11 0x0000560d8c3df423 in handle_stop (it=0x7ffeb78b4820) at xdisp.c:3854
> > #12 0x0000560d8c3ee685 in next_element_from_string (it=0x7ffeb78b4820)
> at xdisp.c:8524
> > #13 0x0000560d8c3ebab6 in get_next_display_element (it=0x7ffeb78b4820)
> at xdisp.c:7500
> > #14 0x0000560d8c42f88f in display_string (string=0x0, lisp_string=...,
> face_string=..., face_string_pos=0,
> > start=0, it=0x7ffeb78b4820, field_width=0, precision=11, max_x=300,
> multibyte=0) at xdisp.c:27323
> > #15 0x0000560d8c42bd6d in display_mode_element (it=0x7ffeb78b4820,
> depth=4, field_width=-23,
> > precision=-23, elt=..., props=..., risky=false) at xdisp.c:25901
>
> Thanks, plugged this one.
>

[-- Attachment #2: Type: text/html, Size: 3271 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Wed, 18 Aug 2021 22:00:57 +0800
> Cc: 44448@debbugs.gnu.org
> 
> Thanks! From what I can tell, the bug is gone. I've been programming in Emacs for a while and haven't
> encountered it.

Thanks, I'm therefore closing the bug.  If you find another
occurrence, please reopen with the relevant data.

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 5140 bytes --]

I'm reopening this as I found another occurrence. Here's the backtrace:

Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=...,
data=..., keyboard_quit=false) at eval.c:1807
1807 {
#0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
eval.c:1807
#1  0x00005600b7049b6b in quit () at eval.c:1797
#2  0x00005600b7049a49 in process_quit_flag () at eval.c:1744
#3  0x00005600b7049a95 in maybe_quit () at eval.c:1764
#4  0x00005600b705c223 in Fdelq (elt=..., list=...) at fns.c:1845
#5  0x00005600b706cf49 in font_put_extra (font=..., prop=..., val=...) at
font.c:749
#6  0x00005600b70757ca in font_clear_prop (attrs=0x7ffd8a5f1620,
prop=FONT_WEIGHT_INDEX) at font.c:3148
#7  0x00005600b6ef3b0d in merge_face_vectors (w=0x5600b8e523a0,
f=0x5600b8e52160, from=0x7ffd8a5f1370, to=0x7ffd8a5f1620,
named_merge_points=0x7ffd8a5f1350) at xfaces.c:2193
#8  0x00005600b6ef4197 in merge_named_face (w=0x5600b8e523a0,
f=0x5600b8e52160, face_name=..., to=0x7ffd8a5f1620,
named_merge_points=0x7ffd8a5f1350, attr_filter=0) at xfaces.c:2309
#9  0x00005600b6ef5afe in merge_face_ref (w=0x5600b8e523a0,
f=0x5600b8e52160, face_ref=..., to=0x7ffd8a5f1620, err_msgs=false,
named_merge_points=0x0, attr_filter=0) at xfaces.c:2793
#10 0x00005600b6ef38e4 in merge_face_vectors (w=0x5600b8e523a0,
f=0x5600b8e52160, from=0x7ffd8a5f16c0, to=0x7ffd8a5f1620,
named_merge_points=0x0) at xfaces.c:2168
#11 0x00005600b6efc11b in lookup_derived_face (w=0x5600b8e523a0,
f=0x5600b8e52160, symbol=..., face_id=4, signal_p=false) at xfaces.c:5006
#12 0x00005600b6df679f in handle_single_display_spec (it=0x7ffd8a5f3060,
spec=..., object=..., overlay=..., position=0x7ffd8a5f31b0, bufpos=7819,
display_replaced=0, frame_window_p=true, enable_eval_p=true) at xdisp.c:5825
#13 0x00005600b6df4858 in handle_display_spec (it=0x7ffd8a5f3060, spec=...,
object=..., overlay=..., position=0x7ffd8a5f31b0, bufpos=7819,
frame_window_p=true) at xdisp.c:5472
#14 0x00005600b6df3ff8 in handle_display_prop (it=0x7ffd8a5f3060) at
xdisp.c:5380
#15 0x00005600b6def7ab in handle_stop (it=0x7ffd8a5f3060) at xdisp.c:3879
#16 0x00005600b6e00d65 in next_element_from_buffer (it=0x7ffd8a5f3060) at
xdisp.c:9126
#17 0x00005600b6dfce4c in get_next_display_element (it=0x7ffd8a5f3060) at
xdisp.c:7713
#18 0x00005600b6e3405f in display_line (it=0x7ffd8a5f3060, cursor_vpos=21)
at xdisp.c:23907
#19 0x00005600b6e2437d in try_window (window=..., pos=..., flags=1) at
xdisp.c:19811
#20 0x00005600b6e20f58 in redisplay_window (window=...,
just_this_one_p=false) at xdisp.c:19218
#21 0x00005600b6e181e9 in redisplay_window_0 (window=...) at xdisp.c:16929
#22 0x00005600b7049210 in internal_condition_case_1 (bfun=0x5600b6e181a3
<redisplay_window_0>, arg=..., handlers=..., hfun=0x5600b6e18167
<redisplay_window_error>) at eval.c:1516
#23 0x00005600b6e18138 in redisplay_windows (window=...) at xdisp.c:16909
#24 0x00005600b6e180ea in redisplay_windows (window=...) at xdisp.c:16903
#25 0x00005600b6e16a6c in redisplay_internal () at xdisp.c:16377
#26 0x00005600b6e178bc in redisplay_preserve_echo_area (from_where=8) at
xdisp.c:16730
#27 0x00005600b6f7d53b in detect_input_pending_run_timers (do_display=true)
at keyboard.c:10457
#28 0x00005600b70c25ed in wait_reading_process_output (time_limit=30,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0,
just_wait_proc=0) at process.c:5697
#29 0x00005600b6dc379c in sit_for (timeout=..., reading=true,
display_option=1) at dispnew.c:6154
#30 0x00005600b6f681d8 in read_char (commandflag=1, map=...,
prev_event=..., used_mouse_menu=0x7ffd8a5f88ed, end_time=0x0) at
keyboard.c:2801
#31 0x00005600b6f7b417 in read_key_sequence (keybuf=0x7ffd8a5f8ad0,
prompt=..., dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9631
#32 0x00005600b6f6384f in command_loop_1 () at keyboard.c:1393
#33 0x00005600b704912d in internal_condition_case (bfun=0x5600b6f633b1
<command_loop_1>, handlers=..., hfun=0x5600b6f627c2 <cmd_error>) at
eval.c:1492
#34 0x00005600b6f62f72 in command_loop_2 (handlers=...) at keyboard.c:1134
#35 0x00005600b70482cc in internal_catch (tag=..., func=0x5600b6f62f47
<command_loop_2>, arg=...) at eval.c:1223
#36 0x00005600b6f62f12 in command_loop () at keyboard.c:1112
#37 0x00005600b6f6226d in recursive_edit_1 () at keyboard.c:721
#38 0x00005600b6f62489 in Frecursive_edit () at keyboard.c:804
#39 0x00005600b6f5e035 in main (argc=1, argv=0x7ffd8a5f8f48) at emacs.c:2409

It happens when the cursor in one window is on an overlay created by
flycheck-mode, and I press C-g in another window.

Eli Zaretskii <eliz@gnu.org> 于2021年8月18日周三 23:47写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Wed, 18 Aug 2021 22:00:57 +0800
> > Cc: 44448@debbugs.gnu.org
> >
> > Thanks! From what I can tell, the bug is gone. I've been programming in
> Emacs for a while and haven't
> > encountered it.
>
> Thanks, I'm therefore closing the bug.  If you find another
> occurrence, please reopen with the relevant data.
>

[-- Attachment #2: Type: text/html, Size: 5737 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Sat, 4 Dec 2021 14:13:09 +0800
> Cc: 44448@debbugs.gnu.org
> 
> I'm reopening this as I found another occurrence. Here's the backtrace:
> 
> Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
> eval.c:1807
> 1807 {
> #0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at eval.c:1807
> #1  0x00005600b7049b6b in quit () at eval.c:1797
> #2  0x00005600b7049a49 in process_quit_flag () at eval.c:1744
> #3  0x00005600b7049a95 in maybe_quit () at eval.c:1764
> #4  0x00005600b705c223 in Fdelq (elt=..., list=...) at fns.c:1845
> #5  0x00005600b706cf49 in font_put_extra (font=..., prop=..., val=...) at font.c:749
> #6  0x00005600b70757ca in font_clear_prop (attrs=0x7ffd8a5f1620, prop=FONT_WEIGHT_INDEX) at
> font.c:3148
> #7  0x00005600b6ef3b0d in merge_face_vectors (w=0x5600b8e523a0, f=0x5600b8e52160,
> from=0x7ffd8a5f1370, to=0x7ffd8a5f1620, named_merge_points=0x7ffd8a5f1350) at xfaces.c:2193
> #8  0x00005600b6ef4197 in merge_named_face (w=0x5600b8e523a0, f=0x5600b8e52160, face_name=...,
> to=0x7ffd8a5f1620, named_merge_points=0x7ffd8a5f1350, attr_filter=0) at xfaces.c:2309
> #9  0x00005600b6ef5afe in merge_face_ref (w=0x5600b8e523a0, f=0x5600b8e52160, face_ref=...,
> to=0x7ffd8a5f1620, err_msgs=false, named_merge_points=0x0, attr_filter=0) at xfaces.c:2793
> #10 0x00005600b6ef38e4 in merge_face_vectors (w=0x5600b8e523a0, f=0x5600b8e52160,
> from=0x7ffd8a5f16c0, to=0x7ffd8a5f1620, named_merge_points=0x0) at xfaces.c:2168
> #11 0x00005600b6efc11b in lookup_derived_face (w=0x5600b8e523a0, f=0x5600b8e52160, symbol=...,
> face_id=4, signal_p=false) at xfaces.c:5006
> #12 0x00005600b6df679f in handle_single_display_spec (it=0x7ffd8a5f3060, spec=..., object=..., overlay=...,
> position=0x7ffd8a5f31b0, bufpos=7819, display_replaced=0, frame_window_p=true, enable_eval_p=true) at
> xdisp.c:5825

Thanks, should be fixed now (on master).

bug#44448: Fwd: bug#44448:

[Amai Kinono]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

I've tested it and it works. Thanks!

Eli Zaretskii <eliz@gnu.org> 于2021年12月4日周六 16:39写道：

> > From: Amai Kinono <amaikinono@gmail.com>
> > Date: Sat, 4 Dec 2021 14:13:09 +0800
> > Cc: 44448@debbugs.gnu.org
> >
> > I'm reopening this as I found another occurrence. Here's the backtrace:
> >
> > Thread 1 "emacs" hit Breakpoint 1, signal_or_quit (error_symbol=...,
> data=..., keyboard_quit=false) at
> > eval.c:1807
> > 1807 {
> > #0  signal_or_quit (error_symbol=..., data=..., keyboard_quit=false) at
> eval.c:1807
> > #1  0x00005600b7049b6b in quit () at eval.c:1797
> > #2  0x00005600b7049a49 in process_quit_flag () at eval.c:1744
> > #3  0x00005600b7049a95 in maybe_quit () at eval.c:1764
> > #4  0x00005600b705c223 in Fdelq (elt=..., list=...) at fns.c:1845
> > #5  0x00005600b706cf49 in font_put_extra (font=..., prop=..., val=...)
> at font.c:749
> > #6  0x00005600b70757ca in font_clear_prop (attrs=0x7ffd8a5f1620,
> prop=FONT_WEIGHT_INDEX) at
> > font.c:3148
> > #7  0x00005600b6ef3b0d in merge_face_vectors (w=0x5600b8e523a0,
> f=0x5600b8e52160,
> > from=0x7ffd8a5f1370, to=0x7ffd8a5f1620,
> named_merge_points=0x7ffd8a5f1350) at xfaces.c:2193
> > #8  0x00005600b6ef4197 in merge_named_face (w=0x5600b8e523a0,
> f=0x5600b8e52160, face_name=...,
> > to=0x7ffd8a5f1620, named_merge_points=0x7ffd8a5f1350, attr_filter=0) at
> xfaces.c:2309
> > #9  0x00005600b6ef5afe in merge_face_ref (w=0x5600b8e523a0,
> f=0x5600b8e52160, face_ref=...,
> > to=0x7ffd8a5f1620, err_msgs=false, named_merge_points=0x0,
> attr_filter=0) at xfaces.c:2793
> > #10 0x00005600b6ef38e4 in merge_face_vectors (w=0x5600b8e523a0,
> f=0x5600b8e52160,
> > from=0x7ffd8a5f16c0, to=0x7ffd8a5f1620, named_merge_points=0x0) at
> xfaces.c:2168
> > #11 0x00005600b6efc11b in lookup_derived_face (w=0x5600b8e523a0,
> f=0x5600b8e52160, symbol=...,
> > face_id=4, signal_p=false) at xfaces.c:5006
> > #12 0x00005600b6df679f in handle_single_display_spec (it=0x7ffd8a5f3060,
> spec=..., object=..., overlay=...,
> > position=0x7ffd8a5f31b0, bufpos=7819, display_replaced=0,
> frame_window_p=true, enable_eval_p=true) at
> > xdisp.c:5825
>
> Thanks, should be fixed now (on master).
>

[-- Attachment #2: Type: text/html, Size: 2760 bytes --]

bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Sat, 4 Dec 2021 19:42:09 +0800
> Cc: 44448@debbugs.gnu.org
> 
> I've tested it and it works. Thanks!

Great, so I'm re-closing the bug.