* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
@ 2023-03-03 13:08 Simon Pugnet
2023-03-03 16:32 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Simon Pugnet @ 2023-03-03 13:08 UTC (permalink / raw)
To: 61940
[[PGP Signed Part:Undecided]]
I've recently (within the last week) noticed that Emacs will crash
when I'm scrolling, specifically when scrolling through a fairly large
PHP source file using either `php-mode' or `web-mode'. I'm not sure
however if this is related to those modes or not.
By "scrolling" I mean holding down a key to move the point up or down.
I am using Evil so this is done by holding "j" or "k".
I'm aware that this isn't very helpful for reproducing the problem
considering that I have so many packages loaded. I've yet to be able
to reproduce this with a simpler configuration, but I'll be sure to
send an update if I do. I am having trouble narrowing down the
packages to find a culprit, but it could also be that my loaded
packages exacerbate the core issue enough to cause a crash.
In addition to this I recently noticed that key presses would
occasionally become out of order. I would start typing something like
"hello world" and I'd notice Emacs pause briefly, then I'd see
something like "llohe world". This was particularly evident when using
Evil as normal state commands like "i" (insert state) would come out
of order, meaning that "ihello" (insert, enter "hello") might become
"lloihe" (move right, move right, new line below and enter insert,
enter "ihe"). I'm not sure if this is related to the crashing bug but
it also started happening at the same time.
The reason that I think it has something to do with visual line
numbers is that the backtrace (below) seems to be within
`display_count_lines_visually'. Also, I've changed the line numbering
mode to relative and I haven't experienced the crash since (although
it's still early days).
I got the following backtrace when attaching to a running instance of
Emacs which crashed. Continuing from this point seems to return to
`XIfEvent' which then ends up back in `poll' (a loop).
(gdb) backtrace
#0 0x00007fe43e7c49df in poll () at /usr/lib/libc.so.6
#1 0x00007fe441fa826b in () at /usr/lib/libxcb.so.1
#2 0x00007fe441fa9d1d in xcb_wait_for_event () at
/usr/lib/libxcb.so.1
#3 0x00007fe44200bb09 in _XReadEvents () at /usr/lib/libX11.so.6
#4 0x00007fe441ff243a in XIfEvent () at /usr/lib/libX11.so.6
#5 0x00007fe442038f10 in () at /usr/lib/libX11.so.6
#6 0x00007fe442030523 in () at /usr/lib/libX11.so.6
#7 0x00007fe44203947c in _XimRead () at /usr/lib/libX11.so.6
#8 0x00007fe442029d6c in () at /usr/lib/libX11.so.6
#9 0x00007fe442014c5f in XSetICValues () at /usr/lib/libX11.so.6
#10 0x000055bdb9993d0b in xic_set_preeditarea (w=0x55bdbb0bd070,
x=175, y=442) at xfns.c:3176
#11 0x000055bdb997f194 in handle_one_xevent
(dpyinfo=dpyinfo@entry=0x55bdbafdfe00,
event=event@entry=0x7ffefbd49710, finish=finish@entry=0x55bdba02e270
<current_finish>, hold_quit=0x7ffefbd499f0) at xterm.c:20116
#12 0x000055bdb9986ec1 in event_handler_gdk (gxev=0x7ffefbd49710,
ev=<optimized out>, data=<optimized out>) at xterm.c:17447
#13 0x00007fe44278a86f in () at /usr/lib/libgdk-3.so.0
#14 0x00007fe442792435 in () at /usr/lib/libgdk-3.so.0
#15 0x00007fe442738029 in gdk_display_get_event () at
/usr/lib/libgdk-3.so.0
#16 0x00007fe4427927c8 in () at /usr/lib/libgdk-3.so.0
#17 0x00007fe44217c82b in g_main_context_dispatch () at
/usr/lib/libglib-2.0.so.0
#18 0x00007fe4421d3cc9 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007fe44217b0e2 in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#20 0x00007fe4429d8f8b in gtk_main_iteration () at
/usr/lib/libgtk-3.so.0
#21 0x000055bdb997183a in XTread_socket (terminal=<optimized out>,
hold_quit=0x7ffefbd499f0) at xterm.c:24819
#22 0x000055bdb99bcf61 in gobble_input () at keyboard.c:7417
#23 0x000055bdb99c0145 in handle_async_input () at keyboard.c:7648
#24 process_pending_signals () at keyboard.c:7662
#25 unblock_input_to (level=0) at keyboard.c:7677
#26 unblock_input_to (level=<optimized out>) at keyboard.c:7671
#27 unblock_input () at keyboard.c:7696
#28 0x000055bdb9ae519b in ftcrfont_text_extents (font=0x55bdbf45e298,
code=<optimized out>, nglyphs=<optimized out>, metrics=0x55bdba018228
<metrics>) at ftcrfont.c:430
#29 0x000055bdb98db630 in get_per_char_metric (char2b=0x7ffefbd49b74,
font=0x55bdbf45e298) at xdisp.c:29632
#30 gui_produce_glyphs (it=0x7ffefbd51220) at xdisp.c:31802
#31 0x000055bdb98c01c8 in move_it_in_display_line_to
(it=it@entry=0x7ffefbd51220, to_charpos=to_charpos@entry=23582,
to_x=to_x@entry=-1, op=op@entry=MOVE_TO_POS) at xdisp.c:9740
#32 0x000055bdb98c5a90 in move_it_to (it=it@entry=0x7ffefbd51220,
to_charpos=to_charpos@entry=23582, to_x=to_x@entry=-1,
to_y=<optimized out>, to_vpos=to_vpos@entry=-1, op=op@entry=10) at
xdisp.c:10361
#33 0x000055bdb98bfe27 in display_count_lines_visually
(it=0x7ffefbd54e10) at xdisp.c:24160
#34 maybe_produce_line_number (it=it@entry=0x7ffefbd54e10) at
xdisp.c:24196
#35 0x000055bdb98cb468 in display_line (it=it@entry=0x7ffefbd54e10,
cursor_vpos=cursor_vpos@entry=26) at xdisp.c:24646
#36 0x000055bdb98ce0e8 in try_window
(window=window@entry=0x55bdbb0bd075, pos=..., flags=flags@entry=1) at
xdisp.c:20576
#37 0x000055bdb98ed238 in redisplay_window (window=0x55bdbb0bd075,
just_this_one_p=just_this_one_p@entry=false) at xdisp.c:19960
#38 0x000055bdb98efa1b in redisplay_window_0
(window=window@entry=0x55bdbb0bd075) at xdisp.c:17446
#39 0x000055bdb9a44ad4 in internal_condition_case_1
(bfun=bfun@entry=0x55bdb98ef9f0 <redisplay_window_0>,
arg=arg@entry=0x55bdbb0bd075, handlers=<optimized out>,
hfun=hfun@entry=0x55bdb98a5960 <redisplay_window_error>) at
eval.c:1498
#40 0x000055bdb98a30a8 in redisplay_windows (window=0x55bdbb0bd075) at
xdisp.c:17416
#41 0x000055bdb98d7ce2 in redisplay_internal () at xdisp.c:16866
#42 0x000055bdb98d9095 in redisplay () at xdisp.c:16049
#43 0x000055bdb99c4483 in read_char (commandflag=1,
map=map@entry=0x55bdbff8db73, prev_event=0x0,
used_mouse_menu=used_mouse_menu@entry=0x7ffefbd5a35b,
end_time=end_time@entry=0x0) at keyboard.c:2627
#44 0x000055bdb99c6db3 in read_key_sequence
(keybuf=keybuf@entry=0x7ffefbd5a490, prompt=prompt@entry=0x0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false) at
keyboard.c:10074
#45 0x000055bdb99c8c75 in command_loop_1 () at keyboard.c:1375
#46 0x000055bdb9a44a47 in internal_condition_case
(bfun=bfun@entry=0x55bdb99c8ab0 <command_loop_1>,
handlers=handlers@entry=0x90, hfun=hfun@entry=0x55bdb99bbac0
<cmd_error>) at eval.c:1474
#47 0x000055bdb99b44d6 in command_loop_2
(handlers=handlers@entry=0x90) at keyboard.c:1124
#48 0x000055bdb9a449a1 in internal_catch (tag=tag@entry=0x10050,
func=func@entry=0x55bdb99b44b0 <command_loop_2>, arg=arg@entry=0x90)
at eval.c:1197
#49 0x000055bdb99b4471 in command_loop () at keyboard.c:1102
#50 0x000055bdb99bb642 in recursive_edit_1 () at keyboard.c:711
#51 0x000055bdb99bb9d0 in Frecursive_edit () at keyboard.c:794
#52 0x000055bdb9886a5f in main (argc=1, argv=0x7ffefbd5a958) at
emacs.c:2529
In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.36, cairo version 1.17.8) of 2023-03-02 built on palenque
Repository revision: a137f71c67e88204a32ebd747beb8fdd7db2fbe9
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version
11.0.12101007
System Description: Arch Linux
Configured using:
'configure --with-native-compilation --with-json --with-modules
--with-tree-sitter'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3
ZLIB
Important settings:
value of $LC_CTYPE: en_GB.UTF-8
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: mu4e:main
Minor modes in effect:
magit-todos-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
mu4e-search-minor-mode: t
mu4e-update-minor-mode: t
mu4e-context-minor-mode: t
editorconfig-mode: t
direnv-mode: t
yas-global-mode: t
which-key-mode: t
marginalia-mode: t
vertico-mode: t
pdf-occur-global-minor-mode: t
lin-global-mode: t
global-evil-surround-mode: t
evil-surround-mode: t
global-evil-matchit-mode: t
evil-matchit-mode: t
evil-commentary-mode: t
global-evil-collection-unimpaired-mode: t
evil-collection-unimpaired-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
evil-mode: t
evil-local-mode: t
windmove-mode: t
global-corfu-mode: t
hexl-follow-ascii: t
shell-dirtrack-mode: t
savehist-mode: t
recentf-mode: t
winner-mode: t
minibuffer-depth-indicate-mode: t
server-mode: t
elpaca-use-package-mode: t
override-global-mode: t
global-hl-line-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-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/simon/.emacs.d/elpaca/builds/lispy/elpa hides
/home/simon/.emacs.d/elpaca/builds/ivy/elpa
/home/simon/.emacs.d/elpaca/builds/let-alist/let-alist hides
/usr/local/share/emacs/29.0.60/lisp/emacs-lisp/let-alist
Features:
(shadow emacsbug vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs
evil-collection-log-view log-view bug-reference
evil-collection-magit-todos magit-todos pcre2el rxt re-builder hl-todo
f
f-shortdoc async magit-bookmark evil-collection-magit magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func magit-diff
smerge-mode git-commit evil-collection-log-edit log-edit pcvs-util
add-log magit-core magit-autorevert autorevert magit-margin
magit-transient magit-process with-editor magit-mode magit-git
magit-base crm evil-collection-profiler profiler gnus-bcklg gnus-async
qp gnus-ml nndraft nnmh epa-file nnfolder nnnil gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg nntp gnus-cache
network-stream
url-cache tabify evil-collection-markdown-mode markdown-mode css-mode
smie sgml-mode facemenu find-dired evil-collection-grep grep
php-flymake
php-mode evil-collection-speedbar speedbar ezimage dframe cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align php-face php
php-project cc-engine cc-vars cc-defs evil-collection-vc-git vc-git
sort
gnus-cite smiley shr-color mm-archive mail-extr textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check ace-window
evil-collection-shortdoc shortdoc org-colview org-crypt org-ctags
org-habit org-mouse org-plot org-protocol ox-hugo ox-hugo-deprecated
ox-blackfriday ox-md tomelr ox-odt rng-loc rng-uri rng-parse rng-match
rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox
org-duration
org-clock evil-collection-view view org-agenda org-indent org-element
org-persist org-id avl-tree oc-basic disp-table ol-eww
evil-collection-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc
ol-info
ol-gnus nnselect ol-docview evil-collection-doc-view doc-view
ol-bibtex
bibtex ol-bbdb ol-w3m ol-doi org-link-doi evil-collection-consult
consult-vertico consult mu4e-alert time ht s alert log4e gntp
evil-collection-mu4e mu4e mu4e-org mu4e-main mu4e-view gnus-art mm-uu
mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range gnus-win mu4e-headers mu4e-compose
mu4e-draft mu4e-actions smtpmail mu4e-search mu4e-lists mu4e-bookmarks
mu4e-mark mu4e-message flow-fill mu4e-contacts mu4e-update
mu4e-folders
mu4e-server mu4e-context mu4e-vars mu4e-helpers mu4e-config ido
message
sendmail yank-media rfc822 mml mml-sec evil-collection-epa epa epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader ement-room-list ement-tabulated-room-list url-http url-auth
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw nsm ement
ement-notify notifications dbus ement-room transient shr pixel-fill
kinsoku url-file ement-lib ement-api ement-structs ement-macros dns
mule-util symex symex-evil symex-evil-support symex-hydra
symex-transformations symex-transformations-lisp symex-utils
evil-cleverparens evil-cleverparens-text-objects
evil-cleverparens-util
smartparens loadhist symex-misc symex-interface-arc
symex-interface-common-lisp evil-collection-sly sly sly-completion
sly-buttons sly-messages sly-common evil-collection-apropos apropos
hyperspec symex-interface-clojure le-clojure evil-collection-cider
cider
tramp-sh cider-debug cider-browse-ns cider-mode cider-find
cider-inspector cider-completion cider-profile cider-eval cider-jar
evil-collection-arc-mode arc-mode archive-mode cider-repl-history
pulse
cider-repl cider-resolve cider-test cider-overlays cider-stacktrace
cider-doc cider-browse-spec cider-clojuredocs cider-eldoc cider-client
cider-common cider-connection cider-util cider-popup sesman-browser
nrepl-client tramp tramp-loaddefs trampver tramp-integration
tramp-compat parse-time iso8601 ls-lisp nrepl-dict spinner sesman vc
vc-dispatcher clojure-mode align parseedn parseclj-parser parseclj-lex
parseclj-alist symex-interface-scheme symex-interface-racket
symex-interface-elisp symex-interop symex-traversals symex-dsl
symex-evaluator symex-computations symex-primitives symex-ts
symex-utils-ts symex-transformations-ts tree-sitter tree-sitter-load
tree-sitter-cli tsc tsc-dyn tsc-dyn-get dired-aux tsc-obsolete
symex-primitives-lisp symex-data symex-ui symex-custom
evil-collection-lispy lispy hydra lv delsel lispy-inline avy etags
fileloop evil-collection-edebug edebug help-fns radix-tree lispy-tags
zoutline elec-pair checkdoc lisp-mnt hideshow rainbow-delimiters
taxy-magit-section evil-collection-magit-section magit-section taxy
plz
evil-collection-realgud realgud realgud-lang-java realgud-zshdb
realgud:zshdb-track-mode realgud:zshdb-core realgud:zshdb-init
realgud-trepan3k realgud:trepan3k-track-mode realgud:trepan3k-core
realgud:trepan3k-init realgud-trepan2 realgud:trepan2-track-mode
realgud:trepan2-core realgud:trepan2-init realgud-trepanpl
realgud:trepanpl-track-mode realgud:trepanpl-core
realgud:trepanpl-init
realgud-trepanjs realgud:trepanjs-track-mode realgud:trepanjs-core
realgud:trepanjs-init realgud-lang-js realgud-trepan
realgud:trepan-track-mode realgud:trepan-core realgud:trepan-init
realgud-remake realgud:remake-track-mode realgud:remake-core
realgud:remake-init realgud-rdebug realgud-rdebug-track-mode
realgud-rdebug-core realgud-rdebug-init realgud-lang-ruby
realgud-perldb
realgud:perldb-track-mode realgud:perldb-core realgud:perldb-init
realgud-lang-perl realgud-pdb realgud:pdb-track-mode realgud:pdb-core
realgud:pdb-init realgud-lang-python realgud-kshdb
realgud:kshdb-track-mode realgud:kshdb-core realgud:kshdb-init
realgud-gub realgud:gub-track-mode realgud:gub-core realgud:gub-init
realgud-gdb realgud:gdb-track-mode realgud:gdb-init realgud:gdb-core
realgud-bashdb realgud:bashdb-track-mode realgud:bashdb-core
realgud:bashdb-init realgud-lang-posix-shell realgud:run
realgud-locals-mode realgud-breakpoint-mode realgud-backtrack-mode
realgud-track-mode realgud-backtrace-mode realgud-track realgud-init
realgud-file realgud-attach realgud-shortkey realgud-menu realgud-eval
realgud-cmds realgud-core realgud-reset realgud-bp
realgud-bp-image-data
realgud-lang realgud-send realgud-window realgud-buffer-helper
realgud-buffer-breakpoint realgud-buffer-backtrace realgud-locals
realgud-buffer-locals realgud-utils evil-collection-eshell em-prompt
esh-mode eshell esh-cmd generator esh-ext esh-opt esh-proc esh-io
esh-arg esh-module esh-groups esh-util cus-start files-x
realgud-buffer-command realgud-buffer-info realgud-regexp
realgud-lochist realgud-loc realgud-buffer-source realgud-key
realgud-custom key realgud-follow loc-changes realgud-fringe
realgud-helper load-relative paredit editorconfig editorconfig-core
editorconfig-core-handle editorconfig-fnmatch direnv
evil-collection-diff-mode diff-mode dash yasnippet-snippets yasnippet
evil-collection-which-key which-key orderless marginalia
evil-collection-vertico vertico pdf-occur ibuf-ext
evil-collection-ibuffer ibuffer ibuffer-loaddefs
evil-collection-tablist
tablist tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag cedet pdf-isearch let-alist pdf-misc evil-collection-pdf
pdf-history pdf-tools evil-collection-package-menu package browse-url
url url-proxy url-privacy url-expand url-methods url-history
url-cookie
generate-lisp-file url-domsuf mailcap url-handlers pdf-view
evil-collection-bookmark bookmark jka-compr pdf-cache pdf-info tq
pdf-util pdf-macs lin face-remap kind-icon svg-lib color svg dom xml
htmlize gnuplot info-look evil-collection-info info evil-surround
evil-numbers evil-matchit evil-matchit-evil-setup evil-matchit-sdk
semantic/lex semantic/fw mode-local evil-exchange evil-commentary
evil-commentary-integration evil-collection-unimpaired
evil-collection-xref evil-collection-tabulated-list
evil-collection-tab-bar evil-collection-simple evil-collection-replace
evil-collection-python evil-collection-process-menu
evil-collection-outline evil-collection-org evil-collection-indent
evil-collection-imenu evil-collection-image-dired
evil-collection-image
evil-collection-help evil-collection-gnus evil-collection-flymake
evil-collection-ert evil-collection-elisp-mode evil-collection-eldoc
evil-collection-eglot evil-collection-dired evil-collection-debug
evil-collection-custom evil-collection-corfu evil-collection-compile
evil-collection-comint evil-collection-calendar calc-ext
evil-collection-calc evil-collection-buff-menu evil-collection
annalist
evil-args evil evil-integration evil-maps evil-commands ffap goto-chg
undo-tree diff queue reveal evil-jumps evil-command-window evil-search
evil-ex evil-types evil-macros evil-repeat evil-states evil-core comp
comp-cstr advice evil-common derived windmove calc calc-loaddefs
calc-macs rect evil-digraphs evil-vars diminish corfu compat
avy-autoloads ace-window-autoloads compat-autoloads consult-autoloads
cape-autoloads comint-mime-autoloads yasnippet-autoloads
consult-yasnippet-autoloads corfu-autoloads diminish-autoloads
elpher-autoloads embark-autoloads embark-consult-autoloads
goto-chg-autoloads evil-autoloads evil-args-autoloads
annalist-autoloads
evil-collection-autoloads evil-commentary-autoloads
evil-exchange-autoloads evil-matchit-autoloads evil-numbers-autoloads
evil-surround-autoloads git-timemachine-autoloads gnuplot-autoloads
gnuplot-mode-autoloads htmlize-autoloads svg-lib-autoloads
kind-icon-autoloads lin-autoloads dash-autoloads with-editor-autoloads
git-commit-autoloads magit-section-autoloads magit-autoloads
async-autoloads s-autoloads f-autoloads hl-todo-autoloads
pcre2el-autoloads magit-todos-autoloads marginalia-autoloads
orderless-autoloads persist-autoloads org-drill-autoloads ht-autoloads
ts-autoloads org-super-agenda-autoloads ov-autoloads peg-autoloads
org-ql-autoloads tomelr-autoloads ox-hugo-autoloads tablist-autoloads
let-alist-autoloads pdf-tools-autoloads plantuml-mode-autoloads
rainbow-delimiters-autoloads rainbow-mode-autoloads wgrep-autoloads
rg-autoloads queue-autoloads undo-tree-autoloads vertico-autoloads
vterm-autoloads which-key-autoloads yasnippet-snippets-autoloads
direnv-autoloads editorconfig-autoloads paredit-autoloads
tsc-autoloads
tree-sitter-autoloads iedit-autoloads ivy-autoloads swiper-autoloads
lv-autoloads hydra-autoloads zoutline-autoloads lispy-autoloads
smartparens-autoloads evil-cleverparens-autoloads symex-autoloads
yaml-mode-autoloads clojure-mode-autoloads parseclj-autoloads
parseedn-autoloads spinner-autoloads sesman-autoloads cider-autoloads
sly-autoloads go-mode-autoloads haskell-mode-autoloads
typescript-mode-autoloads php-mode-autoloads load-relative-autoloads
loc-changes-autoloads test-simple-autoloads realgud-autoloads
realgud-recursive-autoloads realgud-xdebug-autoloads
rust-mode-autoloads
markdown-mode-autoloads xterm-color-autoloads rustic-autoloads
web-mode-autoloads elfeed-autoloads elfeed-org-autoloads
gntp-autoloads
log4e-autoloads alert-autoloads mu4e-alert-autoloads plz-autoloads
taxy-autoloads taxy-magit-section-autoloads ement-autoloads
emms-autoloads subed-autoloads hexl gnutls puny bindat eglot
external-completion array filenotify jsonrpc ert ewoc debug backtrace
xref flymake-proc flymake thingatpt warnings compile url-util imenu
ob-shell shell ob-python python project treesit ob-plantuml ob-latex
ob-js ob-haskell ob-gnuplot ob-dot ob-ditaa org-capture org-refile org
ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint
org-pcomplete pcomplete comint ansi-osc ansi-color org-list
org-footnote
org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol rx org-fold org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec image-dired image-dired-tags
image-dired-external image-dired-util xdg image-mode exif dired
dired-loaddefs gnus nnheader gnus-util text-property-search time-date
mail-utils range mm-util mail-prsvr url-parse auth-source eieio
eieio-core password-cache json map byte-opt url-vars edmacro kmacro
savehist recentf tree-widget modus-operandi-theme modus-themes pcase
subr-x winner ring mb-depth server elpaca-use-package use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core bytecomp
byte-compile elpaca-use-package-autoloads cl-extra help-mode cl-macs
gv
cl-seq elpaca elpaca-process elpaca-autoloads hl-line cus-edit pp
cus-load icons wid-edit cl-loaddefs cl-lib display-line-numbers rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode 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 lisp-mode prog-mode
register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet
lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj
charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray
oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable
backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x
multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 2231115 215244)
(symbols 48 84831 8)
(strings 32 457526 19068)
(string-bytes 1 13527918)
(vectors 16 205244)
(vector-slots 8 4624363 342745)
(floats 8 1072 1779)
(intervals 56 84416 3752)
(buffers 984 72))
[[End of PGP Signed Part]]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-03 13:08 bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Simon Pugnet
@ 2023-03-03 16:32 ` Eli Zaretskii
2023-03-03 16:38 ` Simon Pugnet
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2023-03-03 16:32 UTC (permalink / raw)
To: Simon Pugnet; +Cc: 61940
> Resent-To: bug-gnu-emacs@gnu.org
> From: Simon Pugnet <simon@polaris64.net>
> Date: Fri, 03 Mar 2023 13:08:42 +0000 (2 hours, 47 minutes, 40 seconds ago)
>
> I've recently (within the last week) noticed that Emacs will crash
> when I'm scrolling, specifically when scrolling through a fairly large
> PHP source file using either `php-mode' or `web-mode'. I'm not sure
> however if this is related to those modes or not.
>
> By "scrolling" I mean holding down a key to move the point up or down.
> I am using Evil so this is done by holding "j" or "k".
>
> I'm aware that this isn't very helpful for reproducing the problem
> considering that I have so many packages loaded. I've yet to be able
> to reproduce this with a simpler configuration, but I'll be sure to
> send an update if I do. I am having trouble narrowing down the
> packages to find a culprit, but it could also be that my loaded
> packages exacerbate the core issue enough to cause a crash.
>
> In addition to this I recently noticed that key presses would
> occasionally become out of order. I would start typing something like
> "hello world" and I'd notice Emacs pause briefly, then I'd see
> something like "llohe world". This was particularly evident when using
> Evil as normal state commands like "i" (insert state) would come out
> of order, meaning that "ihello" (insert, enter "hello") might become
> "lloihe" (move right, move right, new line below and enter insert,
> enter "ihe"). I'm not sure if this is related to the crashing bug but
> it also started happening at the same time.
>
> The reason that I think it has something to do with visual line
> numbers is that the backtrace (below) seems to be within
> `display_count_lines_visually'. Also, I've changed the line numbering
> mode to relative and I haven't experienced the crash since (although
> it's still early days).
>
> I got the following backtrace when attaching to a running instance of
> Emacs which crashed.
I'm not sure I understand what you mean by "attaching to a running
instance of Emacs which crashed". If Emacs crashed, then it no longer
is running, so what exactly happens when Emacs "crashes", and how do
you attach GDB to such a "crashed" session?
> Continuing from this point seems to return to `XIfEvent' which then
> ends up back in `poll' (a loop).
This backtrace just says Emacs is reading input, and that you have an
X input method enabled. I'm not sure it tells us anything about the
crash itself. Please run Emacs under GDB to begin with, and then try
to reproduce the crash. When it does crash, please type at the GDB
prompt:
thread apply all bt
and post here the output.
Let me know if you need more detailed instructions for doing the
above, or if something is unclear.
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-03 16:32 ` Eli Zaretskii
@ 2023-03-03 16:38 ` Simon Pugnet
2023-03-03 18:26 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Simon Pugnet @ 2023-03-03 16:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61940
[-- Attachment #1: Type: text/plain, Size: 3491 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> Resent-To: bug-gnu-emacs@gnu.org
>> From: Simon Pugnet <simon@polaris64.net>
>> Date: Fri, 03 Mar 2023 13:08:42 +0000 (2 hours, 47 minutes, 40
>> seconds ago)
>>
>> I've recently (within the last week) noticed that Emacs will crash
>> when I'm scrolling, specifically when scrolling through a fairly
>> large
>> PHP source file using either `php-mode' or `web-mode'. I'm not sure
>> however if this is related to those modes or not.
>>
>> By "scrolling" I mean holding down a key to move the point up or
>> down.
>> I am using Evil so this is done by holding "j" or "k".
>>
>> I'm aware that this isn't very helpful for reproducing the problem
>> considering that I have so many packages loaded. I've yet to be
>> able
>> to reproduce this with a simpler configuration, but I'll be sure to
>> send an update if I do. I am having trouble narrowing down the
>> packages to find a culprit, but it could also be that my loaded
>> packages exacerbate the core issue enough to cause a crash.
>>
>> In addition to this I recently noticed that key presses would
>> occasionally become out of order. I would start typing something
>> like
>> "hello world" and I'd notice Emacs pause briefly, then I'd see
>> something like "llohe world". This was particularly evident when
>> using
>> Evil as normal state commands like "i" (insert state) would come
>> out
>> of order, meaning that "ihello" (insert, enter "hello") might
>> become
>> "lloihe" (move right, move right, new line below and enter insert,
>> enter "ihe"). I'm not sure if this is related to the crashing bug
>> but
>> it also started happening at the same time.
>>
>> The reason that I think it has something to do with visual line
>> numbers is that the backtrace (below) seems to be within
>> `display_count_lines_visually'. Also, I've changed the line
>> numbering
>> mode to relative and I haven't experienced the crash since
>> (although
>> it's still early days).
>>
>> I got the following backtrace when attaching to a running instance
>> of
>> Emacs which crashed.
>
> I'm not sure I understand what you mean by "attaching to a running
> instance of Emacs which crashed". If Emacs crashed, then it no
> longer
> is running, so what exactly happens when Emacs "crashes", and how do
> you attach GDB to such a "crashed" session?
I used `gdb --pid=PID' to attach to the process which had crashed (or
was at least not redrawing or accepting any user input). From there I
obtained the backtrace and was able to step, which is how I noticed
that it seemed to be in a loop. I might have diagnosed this
incorrectly however.
>> Continuing from this point seems to return to `XIfEvent' which then
>> ends up back in `poll' (a loop).
>
> This backtrace just says Emacs is reading input, and that you have
> an
> X input method enabled. I'm not sure it tells us anything about the
> crash itself. Please run Emacs under GDB to begin with, and then
> try
> to reproduce the crash. When it does crash, please type at the GDB
> prompt:
>
> thread apply all bt
>
> and post here the output.
>
> Let me know if you need more detailed instructions for doing the
> above, or if something is unclear.
OK I'll be sure to do that. It might have to be next week as the issue
only appears on my office machine at present, but as soon as I've been
able to do what you ask then I'll reply with the details.
Thanks for your help.
--
Simon Pugnet
https://www.polaris64.net/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-03 16:38 ` Simon Pugnet
@ 2023-03-03 18:26 ` Eli Zaretskii
2023-03-06 11:53 ` Simon Pugnet
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2023-03-03 18:26 UTC (permalink / raw)
To: Simon Pugnet; +Cc: 61940
> From: Simon Pugnet <simon@polaris64.net>
> Cc: 61940@debbugs.gnu.org
> Date: Fri, 03 Mar 2023 16:38:00 +0000
>
> > I'm not sure I understand what you mean by "attaching to a running
> > instance of Emacs which crashed". If Emacs crashed, then it no
> > longer
> > is running, so what exactly happens when Emacs "crashes", and how do
> > you attach GDB to such a "crashed" session?
>
> I used `gdb --pid=PID' to attach to the process which had crashed (or
> was at least not redrawing or accepting any user input).
This seems to indicate that Emacs didn't crash, but stop responding
for some reason. In which case the backtrace you show doesn't tell
anything interesting, it just tells us that Emacs is waiting for
input.
> From there I obtained the backtrace and was able to step, which is
> how I noticed that it seemed to be in a loop. I might have diagnosed
> this incorrectly however.
The file etc/DEBUG in the Emacs repository has instructions for how to
identify the code in which Emacs is looping, if it's looping. Look
for "If the symptom of the bug is that Emacs fails to respond".
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-03 18:26 ` Eli Zaretskii
@ 2023-03-06 11:53 ` Simon Pugnet
2023-03-06 12:21 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Simon Pugnet @ 2023-03-06 11:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61940
[-- Attachment #1: Type: text/plain, Size: 13150 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Simon Pugnet <simon@polaris64.net>
>> Cc: 61940@debbugs.gnu.org
>> Date: Fri, 03 Mar 2023 16:38:00 +0000
>>
>> > I'm not sure I understand what you mean by "attaching to a
>> > running
>> > instance of Emacs which crashed". If Emacs crashed, then it no
>> > longer
>> > is running, so what exactly happens when Emacs "crashes", and how
>> > do
>> > you attach GDB to such a "crashed" session?
>>
>> I used `gdb --pid=PID' to attach to the process which had crashed
>> (or
>> was at least not redrawing or accepting any user input).
>
> This seems to indicate that Emacs didn't crash, but stop responding
> for some reason. In which case the backtrace you show doesn't tell
> anything interesting, it just tells us that Emacs is waiting for
> input.
Sorry, yes I realise now that I said "crash" in the subject but I
meant that it hung or stopped responding to input. What I see when
this happens is a plain white frame (background colour of the theme)
and no keyboard or mouse input seems to be accepted.
>> From there I obtained the backtrace and was able to step, which is
>> how I noticed that it seemed to be in a loop. I might have
>> diagnosed
>> this incorrectly however.
>
> The file etc/DEBUG in the Emacs repository has instructions for how
> to
> identify the code in which Emacs is looping, if it's looping. Look
> for "If the symptom of the bug is that Emacs fails to respond".
I managed to trigger this situation again this morning while working.
Unfortunately I was unable to trigger it while it was being debugged
in gdb; the problem occurs rarely so it's not easy to reproduce on
demand.
I tried sending a SIGUSR2 signal to the running process multiple times
but this did not appear to have any effect.
I again attached to the running process with gdb and ran "thread apply
all bt" as instructed, here's the output: -
Thread 5 (Thread 0x7f11d37fe6c0 (LWP 35081) "threaded-ml"):
#0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
#1 0x00007f11e051f8c7 in () at /usr/lib/libpulse.so.0
#2 0x00007f11e050946c in pa_mainloop_poll () at
/usr/lib/libpulse.so.0
#3 0x00007f11e051342c in pa_mainloop_iterate () at
/usr/lib/libpulse.so.0
#4 0x00007f11e05134e1 in pa_mainloop_run () at /usr/lib/libpulse.so.0
#5 0x00007f11e0523c02 in () at /usr/lib/libpulse.so.0
#6 0x00007f11e04c0c57 in () at
/usr/lib/pulseaudio/libpulsecommon-16.1.so
#7 0x00007f11e8c9ebb5 in () at /usr/lib/libc.so.6
#8 0x00007f11e8d20d90 in () at /usr/lib/libc.so.6
Thread 4 (Thread 0x7f11e23756c0 (LWP 35076) "dconf worker"):
#0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
#1 0x00007f11ec662c2f in () at /usr/lib/libglib-2.0.so.0
#2 0x00007f11ec60a0e2 in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#3 0x00007f11e23cefde in () at
/usr/lib/gio/modules/libdconfsettings.so
#4 0x00007f11ec638db5 in () at /usr/lib/libglib-2.0.so.0
#5 0x00007f11e8c9ebb5 in () at /usr/lib/libc.so.6
#6 0x00007f11e8d20d90 in () at /usr/lib/libc.so.6
Thread 3 (Thread 0x7f11e2bf96c0 (LWP 35075) "gdbus"):
#0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
#1 0x00007f11ec662c2f in () at /usr/lib/libglib-2.0.so.0
#2 0x00007f11ec60ad8f in g_main_loop_run () at
/usr/lib/libglib-2.0.so.0
#3 0x00007f11ec860aec in () at /usr/lib/libgio-2.0.so.0
#4 0x00007f11ec638db5 in () at /usr/lib/libglib-2.0.so.0
#5 0x00007f11e8c9ebb5 in () at /usr/lib/libc.so.6
#6 0x00007f11e8d20d90 in () at /usr/lib/libc.so.6
Thread 2 (Thread 0x7f11e33fa6c0 (LWP 35074) "gmain"):
#0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
#1 0x00007f11ec662c2f in () at /usr/lib/libglib-2.0.so.0
#2 0x00007f11ec60a0e2 in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#3 0x00007f11ec60a132 in () at /usr/lib/libglib-2.0.so.0
#4 0x00007f11ec638db5 in () at /usr/lib/libglib-2.0.so.0
#5 0x00007f11e8c9ebb5 in () at /usr/lib/libc.so.6
#6 0x00007f11e8d20d90 in () at /usr/lib/libc.so.6
Thread 1 (Thread 0x7f11e55fa2c0 (LWP 35073) "emacs"):
#0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
#1 0x00007f11ec43726b in () at /usr/lib/libxcb.so.1
#2 0x00007f11ec438d1d in xcb_wait_for_event () at
/usr/lib/libxcb.so.1
#3 0x00007f11ec49ab09 in _XReadEvents () at /usr/lib/libX11.so.6
#4 0x00007f11ec48143a in XIfEvent () at /usr/lib/libX11.so.6
#5 0x00007f11ec4c7f10 in () at /usr/lib/libX11.so.6
#6 0x00007f11ec4bf523 in () at /usr/lib/libX11.so.6
#7 0x00007f11ec4c847c in _XimRead () at /usr/lib/libX11.so.6
#8 0x00007f11ec4b8d6c in () at /usr/lib/libX11.so.6
#9 0x00007f11ec4a3c5f in XSetICValues () at /usr/lib/libX11.so.6
#10 0x0000563eb62f9d0b in xic_set_preeditarea (w=0x563ec43bdc60,
x=287, y=493) at xfns.c:3176
#11 0x0000563eb62e5194 in handle_one_xevent
(dpyinfo=dpyinfo@entry=0x563eb8c67800,
event=event@entry=0x7ffce40dc7e0, finish=finish@entry=0x563eb6994270
<current_finish>, hold_quit=0x7ffce40dcac0) at xterm.c:20116
#12 0x0000563eb62ecec1 in event_handler_gdk (gxev=0x7ffce40dc7e0,
ev=<optimized out>, data=<optimized out>) at xterm.c:17447
#13 0x00007f11ed4d1b0f in () at /usr/lib/libgdk-3.so.0
#14 0x00007f11ed4d96d5 in () at /usr/lib/libgdk-3.so.0
#15 0x00007f11ed47f029 in gdk_display_get_event () at
/usr/lib/libgdk-3.so.0
#16 0x00007f11ed4d9a68 in () at /usr/lib/libgdk-3.so.0
#17 0x00007f11ec60b82b in g_main_context_dispatch () at
/usr/lib/libglib-2.0.so.0
#18 0x00007f11ec662cc9 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007f11ec60a0e2 in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#20 0x00007f11ecdd8eeb in gtk_main_iteration () at
/usr/lib/libgtk-3.so.0
#21 0x0000563eb62d783a in XTread_socket (terminal=<optimized out>,
hold_quit=0x7ffce40dcac0) at xterm.c:24819
#22 0x0000563eb6322f61 in gobble_input () at keyboard.c:7417
#23 0x0000563eb6323335 in handle_async_input () at keyboard.c:7648
#24 process_pending_signals () at keyboard.c:7662
#25 0x0000563eb63ac12d in probably_quit () at eval.c:1661
#26 0x0000563eb63c0a50 in maybe_quit () at
/storage/Work/personal/emacs/src/lisp.h:3689
#27 Fassoc (key=0x7f11e4b9eb0c, alist=0x7f11e501828b, testfn=0x0) at
fns.c:1969
#28 0x0000563eb6338ab4 in silly_event_symbol_error (c=0xb6d0) at
keymap.c:1476
#29 Fdefine_key (keymap=0x563ebcc2ab53, key=0x563eb91ea1f5,
def=0x563ebc515d0d, remove=0x0) at keymap.c:1165
#30 0x00007f11d11835c8 in
F666c796d616b652d2d6d6f64652d6c696e652d636f756e746572_flymake__mode_line_counter_0
() at
/home/simon/.emacs.d/eln-cache/29.0.60-eff26154/flymake-a41dd277-ddccfc08.eln
#31 0x0000563eb63b0247 in eval_sub (form=form@entry=0x563ebb1208c3) at
eval.c:2501
#32 0x0000563eb63b2876 in Feval (form=0x563ebb1208c3,
lexical=<optimized out>) at eval.c:2361
#33 0x0000563eb63ac3b6 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7ffce40dcfc0) at eval.c:2995
#34 0x0000563eb63aace1 in internal_condition_case_n
(bfun=0x563eb63ac2c0 <Ffuncall>, nargs=nargs@entry=2,
args=args@entry=0x7ffce40dcfc0, handlers=handlers@entry=0x30,
hfun=hfun@entry=0x563eb621cb60 <safe_eval_handler>) at eval.c:1558
#35 0x0000563eb6207ecb in safe__call
(inhibit_quit=inhibit_quit@entry=true, nargs=nargs@entry=2,
func=func@entry=0x6930, ap=ap@entry=0x7ffce40dd040) at xdisp.c:3024
#36 0x0000563eb6207ff0 in safe__call1
(inhibit_quit=inhibit_quit@entry=true, fn=fn@entry=0x6930) at
xdisp.c:3060
#37 0x0000563eb62389a5 in safe__eval (sexpr=<optimized out>,
inhibit_quit=true) at xdisp.c:3074
#38 display_mode_element (it=it@entry=0x7ffce40ddb50, depth=15,
depth@entry=13, field_width=0, precision=precision@entry=-101,
elt=0x563ebb1208b3, props=props@entry=0x7f11e4a9ac13, risky=false) at
xdisp.c:27205
#39 0x0000563eb6238b21 in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=13, depth@entry=12,
field_width=field_width@entry=-8, precision=precision@entry=-100,
elt=0x563ebb120ed3, props=0x7f11e4a9ac13, risky=<optimized out>) at
/storage/Work/personal/emacs/src/lisp.h:754
#40 0x0000563eb62371ff in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=12, depth@entry=10,
field_width=-8, precision=precision@entry=-100, elt=0x563ebb120813,
props=props@entry=0x7f11e4a9ac13, risky=false) at xdisp.c:27228
#41 0x0000563eb6238b21 in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=10, depth@entry=7, field_width=0,
precision=precision@entry=-92, elt=0x563ebb120e13,
props=props@entry=0x7f11e4a9ac13, risky=<optimized out>) at
/storage/Work/personal/emacs/src/lisp.h:754
#42 0x0000563eb6238b21 in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=7, depth@entry=5, field_width=0,
precision=precision@entry=-80, elt=0x563ebb405ed3,
props=props@entry=0x7f11e4a9ac13, risky=<optimized out>) at
/storage/Work/personal/emacs/src/lisp.h:754
#43 0x0000563eb6238b21 in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=5, depth@entry=4,
field_width=field_width@entry=0, precision=precision@entry=-80,
elt=0x7f11e4a9aca3, props=0x7f11e4a9ac13, risky=<optimized out>) at
/storage/Work/personal/emacs/src/lisp.h:754
#44 0x0000563eb62371ff in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=4, depth@entry=3, field_width=0,
precision=precision@entry=-80, elt=0x7f11e4a9abf3,
props=props@entry=0x0, risky=false) at xdisp.c:27228
#45 0x0000563eb6238b21 in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=3, depth@entry=1, field_width=0,
precision=precision@entry=-76, elt=0x7f11e4a9a8ab,
props=props@entry=0x0, risky=<optimized out>) at
/storage/Work/personal/emacs/src/lisp.h:754
#46 0x0000563eb6238b21 in display_mode_element
(it=it@entry=0x7ffce40ddb50, depth=1, depth@entry=0,
field_width=field_width@entry=0, precision=precision@entry=0,
elt=0x7f11e470fadb, elt@entry=0x7f11e470fa4b, props=props@entry=0x0,
risky=<optimized out>) at /storage/Work/personal/emacs/src/lisp.h:754
#47 0x0000563eb623a620 in display_mode_line (w=w@entry=0x563ec43bdc60,
face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x7f11e470fa4b) at
xdisp.c:26717
#48 0x0000563eb623c8ad in display_mode_lines
(w=w@entry=0x563ec43bdc60) at xdisp.c:26630
#49 0x0000563eb6251d39 in redisplay_window (window=0x563ec43bdc65,
just_this_one_p=just_this_one_p@entry=false) at xdisp.c:20364
#50 0x0000563eb6255a1b in redisplay_window_0
(window=window@entry=0x563ec43bdc65) at xdisp.c:17446
#51 0x0000563eb63aaad4 in internal_condition_case_1
(bfun=bfun@entry=0x563eb62559f0 <redisplay_window_0>,
arg=arg@entry=0x563ec43bdc65, handlers=<optimized out>,
hfun=hfun@entry=0x563eb620b960 <redisplay_window_error>) at
eval.c:1498
#52 0x0000563eb62090a8 in redisplay_windows (window=0x563ec43bdc65) at
xdisp.c:17416
#53 0x0000563eb623dce2 in redisplay_internal () at xdisp.c:16866
#54 0x0000563eb623f095 in redisplay () at xdisp.c:16049
#55 0x0000563eb632a483 in read_char (commandflag=1,
map=map@entry=0x563ec421b423, prev_event=0x0,
used_mouse_menu=used_mouse_menu@entry=0x7ffce40e30db,
end_time=end_time@entry=0x0) at keyboard.c:2627
#56 0x0000563eb632cdb3 in read_key_sequence
(keybuf=keybuf@entry=0x7ffce40e3210, prompt=prompt@entry=0x0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false) at keyboard.c:10074
#57 0x0000563eb632ec75 in command_loop_1 () at keyboard.c:1375
#58 0x0000563eb63aaa47 in internal_condition_case
(bfun=bfun@entry=0x563eb632eab0 <command_loop_1>,
handlers=handlers@entry=0x90, hfun=hfun@entry=0x563eb6321ac0
<cmd_error>) at eval.c:1474
#59 0x0000563eb631a4d6 in command_loop_2
(handlers=handlers@entry=0x90) at keyboard.c:1124
#60 0x0000563eb63aa9a1 in internal_catch (tag=tag@entry=0x10050,
func=func@entry=0x563eb631a4b0 <command_loop_2>, arg=arg@entry=0x90)
at eval.c:1197
#61 0x0000563eb631a471 in command_loop () at keyboard.c:1102
#62 0x0000563eb6321642 in recursive_edit_1 () at keyboard.c:711
#63 0x0000563eb63219d0 in Frecursive_edit () at keyboard.c:794
#64 0x0000563eb61eca5f in main (argc=1, argv=0x7ffce40e36d8) at
emacs.c:2529
I tried using the "finish" gdb command from this point and here is
what happened: -
(gdb) finish
Run till exit from #0 0x00007f11e8d139df in poll () from
/usr/lib/libc.so.6
0x00007f11ec43726b in ?? () from /usr/lib/libxcb.so.1
(gdb) finish
Run till exit from #0 0x00007f11ec43726b in ?? () from
/usr/lib/libxcb.so.1
0x00007f11ec438d1d in xcb_wait_for_event () from /usr/lib/libxcb.so.1
(gdb) finish
Run till exit from #0 0x00007f11ec438d1d in xcb_wait_for_event ()
from /usr/lib/libxcb.so.1
0x00007f11ec49ab09 in _XReadEvents () from /usr/lib/libX11.so.6
(gdb) finish
Run till exit from #0 0x00007f11ec49ab09 in _XReadEvents () from
/usr/lib/libX11.so.6
0x00007f11ec48143a in XIfEvent () from /usr/lib/libX11.so.6
(gdb) finish
Run till exit from #0 0x00007f11ec48143a in XIfEvent () from
/usr/lib/libX11.so.6
(at this point the "finish" command does not return).
I hope that helps. I will try to reproduce the problem while running
in gdb and I will send an update if I'm successful.
Kind regards,
--
Simon Pugnet
https://www.polaris64.net/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 11:53 ` Simon Pugnet
@ 2023-03-06 12:21 ` Eli Zaretskii
2023-03-06 12:43 ` Simon Pugnet
2023-03-06 13:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2023-03-06 12:21 UTC (permalink / raw)
To: Simon Pugnet, Po Lu; +Cc: 61940
> From: Simon Pugnet <simon@polaris64.net>
> Cc: 61940@debbugs.gnu.org
> Date: Mon, 06 Mar 2023 11:53:27 +0000
>
> Sorry, yes I realise now that I said "crash" in the subject but I
> meant that it hung or stopped responding to input. What I see when
> this happens is a plain white frame (background colour of the theme)
> and no keyboard or mouse input seems to be accepted.
>
>
> >> From there I obtained the backtrace and was able to step, which is
> >> how I noticed that it seemed to be in a loop. I might have
> >> diagnosed
> >> this incorrectly however.
> >
> > The file etc/DEBUG in the Emacs repository has instructions for how
> > to
> > identify the code in which Emacs is looping, if it's looping. Look
> > for "If the symptom of the bug is that Emacs fails to respond".
>
> I managed to trigger this situation again this morning while working.
> Unfortunately I was unable to trigger it while it was being debugged
> in gdb; the problem occurs rarely so it's not easy to reproduce on
> demand.
You can simply run Emacs under GDB at all times. As long as Emacs
runs normally, GDB will stay out of the way.
> Thread 1 (Thread 0x7f11e55fa2c0 (LWP 35073) "emacs"):
> #0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
> #1 0x00007f11ec43726b in () at /usr/lib/libxcb.so.1
> #2 0x00007f11ec438d1d in xcb_wait_for_event () at
> /usr/lib/libxcb.so.1
> #3 0x00007f11ec49ab09 in _XReadEvents () at /usr/lib/libX11.so.6
> #4 0x00007f11ec48143a in XIfEvent () at /usr/lib/libX11.so.6
> #5 0x00007f11ec4c7f10 in () at /usr/lib/libX11.so.6
> #6 0x00007f11ec4bf523 in () at /usr/lib/libX11.so.6
> #7 0x00007f11ec4c847c in _XimRead () at /usr/lib/libX11.so.6
> #8 0x00007f11ec4b8d6c in () at /usr/lib/libX11.so.6
> #9 0x00007f11ec4a3c5f in XSetICValues () at /usr/lib/libX11.so.6
> #10 0x0000563eb62f9d0b in xic_set_preeditarea (w=0x563ec43bdc60,
> x=287, y=493) at xfns.c:3176
> #11 0x0000563eb62e5194 in handle_one_xevent
> (dpyinfo=dpyinfo@entry=0x563eb8c67800,
> event=event@entry=0x7ffce40dc7e0, finish=finish@entry=0x563eb6994270
> <current_finish>, hold_quit=0x7ffce40dcac0) at xterm.c:20116
> #12 0x0000563eb62ecec1 in event_handler_gdk (gxev=0x7ffce40dc7e0,
> ev=<optimized out>, data=<optimized out>) at xterm.c:17447
> #13 0x00007f11ed4d1b0f in () at /usr/lib/libgdk-3.so.0
> #14 0x00007f11ed4d96d5 in () at /usr/lib/libgdk-3.so.0
> #15 0x00007f11ed47f029 in gdk_display_get_event () at
> /usr/lib/libgdk-3.so.0
> #16 0x00007f11ed4d9a68 in () at /usr/lib/libgdk-3.so.0
> #17 0x00007f11ec60b82b in g_main_context_dispatch () at
> /usr/lib/libglib-2.0.so.0
> #18 0x00007f11ec662cc9 in () at /usr/lib/libglib-2.0.so.0
> #19 0x00007f11ec60a0e2 in g_main_context_iteration () at
> /usr/lib/libglib-2.0.so.0
> #20 0x00007f11ecdd8eeb in gtk_main_iteration () at
> /usr/lib/libgtk-3.so.0
> #21 0x0000563eb62d783a in XTread_socket (terminal=<optimized out>,
> hold_quit=0x7ffce40dcac0) at xterm.c:24819
> #22 0x0000563eb6322f61 in gobble_input () at keyboard.c:7417
> #23 0x0000563eb6323335 in handle_async_input () at keyboard.c:7648
> #24 process_pending_signals () at keyboard.c:7662
> #25 0x0000563eb63ac12d in probably_quit () at eval.c:1661
> #26 0x0000563eb63c0a50 in maybe_quit () at
> /storage/Work/personal/emacs/src/lisp.h:3689
This again says that Emacs is trying to read input via XIM. Maybe Po
Lu could help us understand what could be going on.
> I tried using the "finish" gdb command from this point and here is
> what happened: -
>
> (gdb) finish
> Run till exit from #0 0x00007f11e8d139df in poll () from
> /usr/lib/libc.so.6
> 0x00007f11ec43726b in ?? () from /usr/lib/libxcb.so.1
> (gdb) finish
> Run till exit from #0 0x00007f11ec43726b in ?? () from
> /usr/lib/libxcb.so.1
> 0x00007f11ec438d1d in xcb_wait_for_event () from /usr/lib/libxcb.so.1
> (gdb) finish
> Run till exit from #0 0x00007f11ec438d1d in xcb_wait_for_event ()
> from /usr/lib/libxcb.so.1
> 0x00007f11ec49ab09 in _XReadEvents () from /usr/lib/libX11.so.6
> (gdb) finish
> Run till exit from #0 0x00007f11ec49ab09 in _XReadEvents () from
> /usr/lib/libX11.so.6
> 0x00007f11ec48143a in XIfEvent () from /usr/lib/libX11.so.6
> (gdb) finish
> Run till exit from #0 0x00007f11ec48143a in XIfEvent () from
> /usr/lib/libX11.so.6
>
> (at this point the "finish" command does not return).
>
> I hope that helps. I will try to reproduce the problem while running
> in gdb and I will send an update if I'm successful.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 12:21 ` Eli Zaretskii
@ 2023-03-06 12:43 ` Simon Pugnet
2023-03-06 13:34 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 13:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 13+ messages in thread
From: Simon Pugnet @ 2023-03-06 12:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Po Lu, 61940
[-- Attachment #1: Type: text/plain, Size: 17134 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Simon Pugnet <simon@polaris64.net>
>> Cc: 61940@debbugs.gnu.org
>> Date: Mon, 06 Mar 2023 11:53:27 +0000
>>
>> I managed to trigger this situation again this morning while
>> working.
>> Unfortunately I was unable to trigger it while it was being
>> debugged
>> in gdb; the problem occurs rarely so it's not easy to reproduce on
>> demand.
>
> You can simply run Emacs under GDB at all times. As long as Emacs
> runs normally, GDB will stay out of the way.
OK, I'm doing that now as we speak.
I think however I've found the culprit: ibus. I noticed that after
this issue occurred and I ended the Emacs process, the compose key
would no longer work in many applications (it still worked in Firefox
however). Also Emacs seemed to be behaving normally again; I wasn't
getting those pauses where keys were getting jumbled any more. I took
a look at the system journal and saw this: -
Mar 06 11:29:46 palenque systemd[1]: Started Process Core Dump (PID
143076/UID 0).
Mar 06 11:29:46 palenque systemd-coredump[143078]: [🡕] Process 1397
(ibus-x11) of user 1000 dumped core.
Stack trace of
thread 1397:
#0
0x00007f8b611bd8ec
n/a (libc.so.6 +
0x878ec)
#1
0x00007f8b6116eea8
raise (libc.so.6 +
0x38ea8)
#2
0x00007f8b6115853d
abort (libc.so.6 +
0x2253d)
#3
0x00007f8b6115929e
n/a (libc.so.6 +
0x2329e)
#4
0x00007f8b611c7657
n/a (libc.so.6 +
0x91657)
#5
0x00007f8b611c9442
n/a (libc.so.6 +
0x93442)
#6
0x00007f8b611cbe63
__libc_free
(libc.so.6 +
0x95e63)
#7
0x00007f8b6135f94e
XFree (libX11.so.6
+ 0x4294e)
#8
0x00005570719e4311
n/a (ibus-x11 +
0xe311)
#9
0x00005570719e619a
n/a (ibus-x11 +
0x1019a)
#10
0x00007f8b61e8159e
n/a (libgdk-3.so.0
+ 0x8b59e)
#11
0x00007f8b61e27029
gdk_display_get_event
(libgdk-3.so.0 +
0x31029)
#12
0x00007f8b61e81a68
n/a (libgdk-3.so.0
+ 0x8ba68)
#13
0x00007f8b614b582b
g_main_context_dispatch
(libglib-2.0.so.0 +
0x5582b)
#14
0x00007f8b6150ccc9
n/a
(libglib-2.0.so.0 +
0xaccc9)
#15
0x00007f8b614b4d8f
g_main_loop_run
(libglib-2.0.so.0 +
0x54d8f)
#16
0x00007f8b61f262b2
ibus_main
(libibus-1.0.so.5 +
0x372b2)
#17
0x00005570719d9505
n/a (ibus-x11 +
0x3505)
#18
0x00007f8b61159790
n/a (libc.so.6 +
0x23790)
#19
0x00007f8b6115984a
__libc_start_main
(libc.so.6 +
0x2384a)
#20
0x00005570719d96f5
n/a (ibus-x11 +
0x36f5)
Stack trace of
thread 1415:
#0
0x00007f8b612309df
__poll (libc.so.6 +
0xfa9df)
#1
0x00007f8b6150cc2f
n/a
(libglib-2.0.so.0 +
0xacc2f)
#2
0x00007f8b614b4d8f
g_main_loop_run
(libglib-2.0.so.0 +
0x54d8f)
#3
0x00007f8b61072aec
n/a
(libgio-2.0.so.0 +
0x10aaec)
#4
0x00007f8b614e2db5
n/a
(libglib-2.0.so.0 +
0x82db5)
#5
0x00007f8b611bbbb5
n/a (libc.so.6 +
0x85bb5)
#6
0x00007f8b6123dd90
n/a (libc.so.6 +
0x107d90)
Stack trace of
thread 1412:
#0
0x00007f8b612309df
__poll (libc.so.6 +
0xfa9df)
#1
0x00007f8b6150cc2f
n/a
(libglib-2.0.so.0 +
0xacc2f)
#2
0x00007f8b614b40e2
g_main_context_iteration
(libglib-2.0.so.0 +
0x540e2)
#3
0x00007f8b614b4132
n/a
(libglib-2.0.so.0 +
0x54132)
#4
0x00007f8b614e2db5
n/a
(libglib-2.0.so.0 +
0x82db5)
#5
0x00007f8b611bbbb5
n/a (libc.so.6 +
0x85bb5)
#6
0x00007f8b6123dd90
n/a (libc.so.6 +
0x107d90)
ELF object binary
architecture: AMD
x86-64
Mar 06 11:29:46 palenque systemd[1]:
systemd-coredump@1-143076-0.service: Deactivated successfully.
I debugged the dumped core and ran "thread apply all bt", this was the
result: -
Thread 3 (Thread 0x7f8b5cfff6c0 (LWP 1412)):
warning: Section `.reg-xstate/1412' in core file too small.
#0 0x00007f8b612309df in __GI___poll (fds=0x557071c51f00, nfds=2,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f8b6150cc2f in g_main_context_poll (priority=<optimized
out>, n_fds=2, fds=0x557071c51f00, timeout=<optimized out>,
context=0x557071c53eb0) at ../glib/glib/gmain.c:4553
#2 g_main_context_iterate.constprop.0 (context=0x557071c53eb0,
block=1, dispatch=1, self=<optimized out>) at
../glib/glib/gmain.c:4243
#3 0x00007f8b614b40e2 in g_main_context_iteration
(context=0x557071c53eb0, may_block=may_block@entry=1) at
../glib/glib/gmain.c:4313
#4 0x00007f8b614b4132 in glib_worker_main (data=<optimized out>) at
../glib/glib/gmain.c:6416
#5 0x00007f8b614e2db5 in g_thread_proxy (data=0x557071c47b00) at
../glib/glib/gthread.c:831
#6 0x00007f8b611bbbb5 in start_thread (arg=<optimized out>) at
pthread_create.c:444
#7 0x00007f8b6123dd90 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 2 (Thread 0x7f8b57fff6c0 (LWP 1415)):
warning: Section `.reg-xstate/1415' in core file too small.
#0 0x00007f8b612309df in __GI___poll (fds=0x557071c646d0, nfds=3,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f8b6150cc2f in g_main_context_poll (priority=<optimized
out>, n_fds=3, fds=0x557071c646d0, timeout=<optimized out>,
context=0x557071c62bf0) at ../glib/glib/gmain.c:4553
#2 g_main_context_iterate.constprop.0 (context=0x557071c62bf0,
block=1, dispatch=1, self=<optimized out>) at
../glib/glib/gmain.c:4243
#3 0x00007f8b614b4d8f in g_main_loop_run (loop=0x557071c62ce0) at
../glib/glib/gmain.c:4448
#4 0x00007f8b61072aec in gdbus_shared_thread_func
(user_data=0x557071c62bc0) at ../glib/gio/gdbusprivate.c:284
#5 0x00007f8b614e2db5 in g_thread_proxy (data=0x557071c5c640) at
../glib/glib/gthread.c:831
#6 0x00007f8b611bbbb5 in start_thread (arg=<optimized out>) at
pthread_create.c:444
#7 0x00007f8b6123dd90 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 1 (Thread 0x7f8b5fd45980 (LWP 1397)):
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007f8b611bd953 in __pthread_kill_internal (signo=6,
threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007f8b6116eea8 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007f8b6115853d in __GI_abort () at abort.c:79
#4 0x00007f8b6115929e in __libc_message (fmt=fmt@entry=0x7f8b612d077e
"%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x00007f8b611c7657 in malloc_printerr
(str=str@entry=0x7f8b612d3590 "double free or corruption (fasttop)")
at malloc.c:5651
#6 0x00007f8b611c9442 in _int_free (av=0x7f8b6130eaa0 <main_arena>,
p=0x557071d50da0, have_lock=have_lock@entry=0) at malloc.c:4525
#7 0x00007f8b611cbe63 in __GI___libc_free
(mem=mem@entry=0x557071d50db0) at malloc.c:3367
#8 0x00007f8b6135f94e in XFree (data=data@entry=0x557071d50db0) at
/usr/src/debug/libx11/libX11-1.8.4/src/XlibInt.c:1633
#9 0x00005570719e4311 in ProcessQueue (connect_id=4,
ims=0x557071e82e50) at ../../util/IMdkit/i18nPtHdr.c:1762
#10 _Xi18nMessageHandler (ims=ims@entry=0x557071e82e50, connect_id=4,
p=p@entry=0x557071db6ab0 ">", delete=delete@entry=0x7ffe74734f84) at
../../util/IMdkit/i18nPtHdr.c:1923
#11 0x00005570719e619a in WaitXIMProtocol (dpy=<optimized out>,
win=<optimized out>, ev=<optimized out>, client_data=0x557071e82e50 "
\t\237qpU") at ../../util/IMdkit/i18nX.c:524
#12 0x00007f8b61e8159e in _gdk_x11_display_queue_events
(display=0x557071bfe0e0) at ../gtk/gdk/x11/gdkeventsource.c:337
#13 0x00007f8b61e27029 in gdk_display_get_event
(display=0x557071bfe0e0) at ../gtk/gdk/gdkdisplay.c:442
#14 0x00007f8b61e81a68 in gdk_event_source_dispatch.lto_priv () at
../gtk/gdk/x11/gdkeventsource.c:354
#15 0x00007f8b614b582b in g_main_dispatch (context=0x557071c27d20) at
../glib/glib/gmain.c:3454
#16 g_main_context_dispatch (context=0x557071c27d20) at
../glib/glib/gmain.c:4172
#17 0x00007f8b6150ccc9 in g_main_context_iterate.constprop.0
(context=0x557071c27d20, block=1, dispatch=1, self=<optimized out>)
at ../glib/glib/gmain.c:4248
#18 0x00007f8b614b4d8f in g_main_loop_run (loop=0x557071d975e0) at
../glib/glib/gmain.c:4448
#19 0x00007f8b61f262b2 in ibus_main () at
/usr/src/debug/ibus/ibus-1.5.28/src/ibusshare.c:327
#20 0x00005570719d9505 in main (argc=<optimized out>, argv=<optimized
out>) at /usr/src/debug/ibus/ibus-1.5.28/client/x11/main.c:1416
So to summarise, I am getting these issues in Emacs while IBus is
being used as my input method. The IBus crash seems to cause Emacs to
hang. Once IBus is no longer running Emacs appears to run normally
again. So it looks like this might be an IBus issue rather than an
Emacs issue, but that's just my best guess from the above.
Kind regards,
--
Simon Pugnet
https://www.polaris64.net/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 12:21 ` Eli Zaretskii
2023-03-06 12:43 ` Simon Pugnet
@ 2023-03-06 13:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 13:19 ` Simon Pugnet
1 sibling, 1 reply; 13+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-06 13:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61940, Simon Pugnet
Eli Zaretskii <eliz@gnu.org> writes:
>> Thread 1 (Thread 0x7f11e55fa2c0 (LWP 35073) "emacs"):
>> #0 0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
>> #1 0x00007f11ec43726b in () at /usr/lib/libxcb.so.1
>> #2 0x00007f11ec438d1d in xcb_wait_for_event () at
>> /usr/lib/libxcb.so.1
>> #3 0x00007f11ec49ab09 in _XReadEvents () at /usr/lib/libX11.so.6
>> #4 0x00007f11ec48143a in XIfEvent () at /usr/lib/libX11.so.6
>> #5 0x00007f11ec4c7f10 in () at /usr/lib/libX11.so.6
>> #6 0x00007f11ec4bf523 in () at /usr/lib/libX11.so.6
>> #7 0x00007f11ec4c847c in _XimRead () at /usr/lib/libX11.so.6
>> #8 0x00007f11ec4b8d6c in () at /usr/lib/libX11.so.6
>> #9 0x00007f11ec4a3c5f in XSetICValues () at /usr/lib/libX11.so.6
>> #10 0x0000563eb62f9d0b in xic_set_preeditarea (w=0x563ec43bdc60,
>> x=287, y=493) at xfns.c:3176
>> #11 0x0000563eb62e5194 in handle_one_xevent
>> (dpyinfo=dpyinfo@entry=0x563eb8c67800,
>> event=event@entry=0x7ffce40dc7e0, finish=finish@entry=0x563eb6994270
>> <current_finish>, hold_quit=0x7ffce40dcac0) at xterm.c:20116
>> #12 0x0000563eb62ecec1 in event_handler_gdk (gxev=0x7ffce40dc7e0,
>> ev=<optimized out>, data=<optimized out>) at xterm.c:17447
>> #13 0x00007f11ed4d1b0f in () at /usr/lib/libgdk-3.so.0
>> #14 0x00007f11ed4d96d5 in () at /usr/lib/libgdk-3.so.0
>> #15 0x00007f11ed47f029 in gdk_display_get_event () at
>> /usr/lib/libgdk-3.so.0
>> #16 0x00007f11ed4d9a68 in () at /usr/lib/libgdk-3.so.0
>> #17 0x00007f11ec60b82b in g_main_context_dispatch () at
>> /usr/lib/libglib-2.0.so.0
>> #18 0x00007f11ec662cc9 in () at /usr/lib/libglib-2.0.so.0
>> #19 0x00007f11ec60a0e2 in g_main_context_iteration () at
>> /usr/lib/libglib-2.0.so.0
>> #20 0x00007f11ecdd8eeb in gtk_main_iteration () at
>> /usr/lib/libgtk-3.so.0
>> #21 0x0000563eb62d783a in XTread_socket (terminal=<optimized out>,
>> hold_quit=0x7ffce40dcac0) at xterm.c:24819
>> #22 0x0000563eb6322f61 in gobble_input () at keyboard.c:7417
>> #23 0x0000563eb6323335 in handle_async_input () at keyboard.c:7648
>> #24 process_pending_signals () at keyboard.c:7662
>> #25 0x0000563eb63ac12d in probably_quit () at eval.c:1661
>> #26 0x0000563eb63c0a50 in maybe_quit () at
>> /storage/Work/personal/emacs/src/lisp.h:3689
>
> This again says that Emacs is trying to read input via XIM. Maybe Po
> Lu could help us understand what could be going on.
Thanks. Would you please verify that the loop does not involve Emacs
calling xic_set_preeditarea over and over again? IOW, break on the line
after 3176 in xfns.c, and see if that breakpoint is ever hit?
Otherwise, I suggest looking in your system logs for crashes involving
the input method framework you are using. Xlib does not know how to
handle IM server crashes, and will either crash trying to access a
nonexistent window or loop waiting for events from the crashed IM
server, which is what I think it's doing here.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 13:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-03-06 13:19 ` Simon Pugnet
0 siblings, 0 replies; 13+ messages in thread
From: Simon Pugnet @ 2023-03-06 13:19 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, 61940
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Po Lu <luangruo@yahoo.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> This again says that Emacs is trying to read input via XIM. Maybe
>> Po
>> Lu could help us understand what could be going on.
>
> Thanks. Would you please verify that the loop does not involve
> Emacs
> calling xic_set_preeditarea over and over again? IOW, break on the
> line
> after 3176 in xfns.c, and see if that breakpoint is ever hit?
>
> Otherwise, I suggest looking in your system logs for crashes
> involving
> the input method framework you are using. Xlib does not know how to
> handle IM server crashes, and will either crash trying to access a
> nonexistent window or loop waiting for events from the crashed IM
> server, which is what I think it's doing here.
Good call, it looks like this is exactly what's happening. Please see
my other reply for details of an IBus crash.
Kind regards,
--
Simon Pugnet
https://www.polaris64.net/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 12:43 ` Simon Pugnet
@ 2023-03-06 13:34 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 14:57 ` Simon Pugnet
0 siblings, 1 reply; 13+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-06 13:34 UTC (permalink / raw)
To: Simon Pugnet; +Cc: Eli Zaretskii, 61940
Simon Pugnet <simon@polaris64.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Simon Pugnet <simon@polaris64.net>
>>> Cc: 61940@debbugs.gnu.org
>>> Date: Mon, 06 Mar 2023 11:53:27 +0000
>>> I managed to trigger this situation again this morning while
>>> working. Unfortunately I was unable to trigger it while it was
>>> being debugged in gdb; the problem occurs rarely so it's not easy
>>> to reproduce on demand.
>>
>> You can simply run Emacs under GDB at all times. As long as Emacs
>> runs normally, GDB will stay out of the way.
>
> OK, I'm doing that now as we speak.
>
> I think however I've found the culprit: ibus. I noticed that after
> this issue occurred and I ended the Emacs process, the compose key
> would no longer work in many applications (it still worked in Firefox
> however). Also Emacs seemed to be behaving normally again; I wasn't
> getting those pauses where keys were getting jumbled any more. I took
> a look at the system journal and saw this: -
The Compose key is handled by ibus in most programs, but AFAIK Firefox
does something else. So I'm not surprised.
> Mar 06 11:29:46 palenque systemd[1]: Started Process Core Dump (PID
> 143076/UID 0).
> Mar 06 11:29:46 palenque systemd-coredump[143078]: [🡕] Process 1397
> (ibus-x11) of user 1000 dumped core.
>
> Stack trace of
> thread 1397:
> #0
> 0x00007f8b611bd8ec
> n/a (libc.so.6 +
> 0x878ec)
> #1
> 0x00007f8b6116eea8
> raise (libc.so.6 +
> 0x38ea8)
> #2
> 0x00007f8b6115853d
> abort (libc.so.6 +
> 0x2253d)
> #3
> 0x00007f8b6115929e
> n/a (libc.so.6 +
> 0x2329e)
> #4
> 0x00007f8b611c7657
> n/a (libc.so.6 +
> 0x91657)
> #5
> 0x00007f8b611c9442
> n/a (libc.so.6 +
> 0x93442)
> #6
> 0x00007f8b611cbe63
> __libc_free
> (libc.so.6 +
> 0x95e63)
> #7
> 0x00007f8b6135f94e
> XFree (libX11.so.6
> + 0x4294e)
> #8
> 0x00005570719e4311
> n/a (ibus-x11 +
> 0xe311)
> #9
> 0x00005570719e619a
> n/a (ibus-x11 +
> 0x1019a)
> #10
> 0x00007f8b61e8159e
> n/a (libgdk-3.so.0
> + 0x8b59e)
> #11
> 0x00007f8b61e27029
> gdk_display_get_event
> (libgdk-3.so.0 +
> 0x31029)
> #12
> 0x00007f8b61e81a68
> n/a (libgdk-3.so.0
> + 0x8ba68)
> #13
> 0x00007f8b614b582b
> g_main_context_dispatch
> (libglib-2.0.so.0 +
> 0x5582b)
> #14
> 0x00007f8b6150ccc9
> n/a
> (libglib-2.0.so.0 +
> 0xaccc9)
> #15
> 0x00007f8b614b4d8f
> g_main_loop_run
> (libglib-2.0.so.0 +
> 0x54d8f)
> #16
> 0x00007f8b61f262b2
> ibus_main
> (libibus-1.0.so.5 +
> 0x372b2)
> #17
> 0x00005570719d9505
> n/a (ibus-x11 +
> 0x3505)
> #18
> 0x00007f8b61159790
> n/a (libc.so.6 +
> 0x23790)
> #19
> 0x00007f8b6115984a
> __libc_start_main
> (libc.so.6 +
> 0x2384a)
> #20
> 0x00005570719d96f5
> n/a (ibus-x11 +
> 0x36f5)
>
> Stack trace of
> thread 1415:
> #0
> 0x00007f8b612309df
> __poll (libc.so.6 +
> 0xfa9df)
> #1
> 0x00007f8b6150cc2f
> n/a
> (libglib-2.0.so.0 +
> 0xacc2f)
> #2
> 0x00007f8b614b4d8f
> g_main_loop_run
> (libglib-2.0.so.0 +
> 0x54d8f)
> #3
> 0x00007f8b61072aec
> n/a
> (libgio-2.0.so.0 +
> 0x10aaec)
> #4
> 0x00007f8b614e2db5
> n/a
> (libglib-2.0.so.0 +
> 0x82db5)
> #5
> 0x00007f8b611bbbb5
> n/a (libc.so.6 +
> 0x85bb5)
> #6
> 0x00007f8b6123dd90
> n/a (libc.so.6 +
> 0x107d90)
>
> Stack trace of
> thread 1412:
> #0
> 0x00007f8b612309df
> __poll (libc.so.6 +
> 0xfa9df)
> #1
> 0x00007f8b6150cc2f
> n/a
> (libglib-2.0.so.0 +
> 0xacc2f)
> #2
> 0x00007f8b614b40e2
> g_main_context_iteration
> (libglib-2.0.so.0 +
> 0x540e2)
> #3
> 0x00007f8b614b4132
> n/a
> (libglib-2.0.so.0 +
> 0x54132)
> #4
> 0x00007f8b614e2db5
> n/a
> (libglib-2.0.so.0 +
> 0x82db5)
> #5
> 0x00007f8b611bbbb5
> n/a (libc.so.6 +
> 0x85bb5)
> #6
> 0x00007f8b6123dd90
> n/a (libc.so.6 +
> 0x107d90)
> ELF object binary
> architecture: AMD
> x86-64
> Mar 06 11:29:46 palenque systemd[1]:
> systemd-coredump@1-143076-0.service: Deactivated successfully.
>
> I debugged the dumped core and ran "thread apply all bt", this was the
> result: -
>
> Thread 3 (Thread 0x7f8b5cfff6c0 (LWP 1412)):
> warning: Section `.reg-xstate/1412' in core file too small.
> #0 0x00007f8b612309df in __GI___poll (fds=0x557071c51f00, nfds=2,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1 0x00007f8b6150cc2f in g_main_context_poll (priority=<optimized
> out>, n_fds=2, fds=0x557071c51f00, timeout=<optimized out>,
> context=0x557071c53eb0) at ../glib/glib/gmain.c:4553
> #2 g_main_context_iterate.constprop.0 (context=0x557071c53eb0,
> block=1, dispatch=1, self=<optimized out>) at
> ../glib/glib/gmain.c:4243
> #3 0x00007f8b614b40e2 in g_main_context_iteration
> (context=0x557071c53eb0, may_block=may_block@entry=1) at
> ../glib/glib/gmain.c:4313
> #4 0x00007f8b614b4132 in glib_worker_main (data=<optimized out>) at
> ../glib/glib/gmain.c:6416
> #5 0x00007f8b614e2db5 in g_thread_proxy (data=0x557071c47b00) at
> ../glib/glib/gthread.c:831
> #6 0x00007f8b611bbbb5 in start_thread (arg=<optimized out>) at
> pthread_create.c:444
> #7 0x00007f8b6123dd90 in clone3 () at
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
>
> Thread 2 (Thread 0x7f8b57fff6c0 (LWP 1415)):
> warning: Section `.reg-xstate/1415' in core file too small.
> #0 0x00007f8b612309df in __GI___poll (fds=0x557071c646d0, nfds=3,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1 0x00007f8b6150cc2f in g_main_context_poll (priority=<optimized
> out>, n_fds=3, fds=0x557071c646d0, timeout=<optimized out>,
> context=0x557071c62bf0) at ../glib/glib/gmain.c:4553
> #2 g_main_context_iterate.constprop.0 (context=0x557071c62bf0,
> block=1, dispatch=1, self=<optimized out>) at
> ../glib/glib/gmain.c:4243
> #3 0x00007f8b614b4d8f in g_main_loop_run (loop=0x557071c62ce0) at
> ../glib/glib/gmain.c:4448
> #4 0x00007f8b61072aec in gdbus_shared_thread_func
> (user_data=0x557071c62bc0) at ../glib/gio/gdbusprivate.c:284
> #5 0x00007f8b614e2db5 in g_thread_proxy (data=0x557071c5c640) at
> ../glib/glib/gthread.c:831
> #6 0x00007f8b611bbbb5 in start_thread (arg=<optimized out>) at
> pthread_create.c:444
> #7 0x00007f8b6123dd90 in clone3 () at
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
>
> Thread 1 (Thread 0x7f8b5fd45980 (LWP 1397)):
> #0 __pthread_kill_implementation (threadid=<optimized out>,
> signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
> #1 0x00007f8b611bd953 in __pthread_kill_internal (signo=6,
> threadid=<optimized out>) at pthread_kill.c:78
> #2 0x00007f8b6116eea8 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/posix/raise.c:26
> #3 0x00007f8b6115853d in __GI_abort () at abort.c:79
> #4 0x00007f8b6115929e in __libc_message (fmt=fmt@entry=0x7f8b612d077e
> "%s\n") at ../sysdeps/posix/libc_fatal.c:150
> #5 0x00007f8b611c7657 in malloc_printerr
> (str=str@entry=0x7f8b612d3590 "double free or corruption (fasttop)")
> at malloc.c:5651
> #6 0x00007f8b611c9442 in _int_free (av=0x7f8b6130eaa0 <main_arena>,
> p=0x557071d50da0, have_lock=have_lock@entry=0) at malloc.c:4525
> #7 0x00007f8b611cbe63 in __GI___libc_free
> (mem=mem@entry=0x557071d50db0) at malloc.c:3367
> #8 0x00007f8b6135f94e in XFree (data=data@entry=0x557071d50db0) at
> /usr/src/debug/libx11/libX11-1.8.4/src/XlibInt.c:1633
> #9 0x00005570719e4311 in ProcessQueue (connect_id=4,
> ims=0x557071e82e50) at ../../util/IMdkit/i18nPtHdr.c:1762
> #10 _Xi18nMessageHandler (ims=ims@entry=0x557071e82e50, connect_id=4,
> p=p@entry=0x557071db6ab0 ">", delete=delete@entry=0x7ffe74734f84) at
> ../../util/IMdkit/i18nPtHdr.c:1923
> #11 0x00005570719e619a in WaitXIMProtocol (dpy=<optimized out>,
> win=<optimized out>, ev=<optimized out>, client_data=0x557071e82e50 "
> \t\237qpU") at ../../util/IMdkit/i18nX.c:524
> #12 0x00007f8b61e8159e in _gdk_x11_display_queue_events
> (display=0x557071bfe0e0) at ../gtk/gdk/x11/gdkeventsource.c:337
> #13 0x00007f8b61e27029 in gdk_display_get_event
> (display=0x557071bfe0e0) at ../gtk/gdk/gdkdisplay.c:442
> #14 0x00007f8b61e81a68 in gdk_event_source_dispatch.lto_priv () at
> ../gtk/gdk/x11/gdkeventsource.c:354
> #15 0x00007f8b614b582b in g_main_dispatch (context=0x557071c27d20) at
> ../glib/glib/gmain.c:3454
> #16 g_main_context_dispatch (context=0x557071c27d20) at
> ../glib/glib/gmain.c:4172
> #17 0x00007f8b6150ccc9 in g_main_context_iterate.constprop.0
> (context=0x557071c27d20, block=1, dispatch=1, self=<optimized out>)
> at ../glib/glib/gmain.c:4248
> #18 0x00007f8b614b4d8f in g_main_loop_run (loop=0x557071d975e0) at
> ../glib/glib/gmain.c:4448
> #19 0x00007f8b61f262b2 in ibus_main () at
> /usr/src/debug/ibus/ibus-1.5.28/src/ibusshare.c:327
> #20 0x00005570719d9505 in main (argc=<optimized out>, argv=<optimized
> out>) at /usr/src/debug/ibus/ibus-1.5.28/client/x11/main.c:1416
>
>
> So to summarise, I am getting these issues in Emacs while IBus is
> being used as my input method. The IBus crash seems to cause Emacs to
> hang. Once IBus is no longer running Emacs appears to run normally
> again. So it looks like this might be an IBus issue rather than an
> Emacs issue, but that's just my best guess from the above.
Please report this to the I-Bus developers. As for the Xlib lock-up,
complain to Fujitsu, who wrote the present XIM implementation in Xlib.
To not use XIM, place:
Emacs.useXIM: false
in your ~/.Xresources or ~/.Xdefaults, and do the usual thing with xrdb
to install the resources.
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 13:34 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-03-06 14:57 ` Simon Pugnet
2023-03-08 14:37 ` Simon Pugnet
0 siblings, 1 reply; 13+ messages in thread
From: Simon Pugnet @ 2023-03-06 14:57 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, 61940
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Po Lu <luangruo@yahoo.com> writes:
> Simon Pugnet <simon@polaris64.net> writes:
>
>> So to summarise, I am getting these issues in Emacs while IBus is
>> being used as my input method. The IBus crash seems to cause Emacs
>> to
>> hang. Once IBus is no longer running Emacs appears to run normally
>> again. So it looks like this might be an IBus issue rather than an
>> Emacs issue, but that's just my best guess from the above.
>
> Please report this to the I-Bus developers. As for the Xlib
> lock-up,
> complain to Fujitsu, who wrote the present XIM implementation in
> Xlib.
>
> To not use XIM, place:
>
> Emacs.useXIM: false
>
> in your ~/.Xresources or ~/.Xdefaults, and do the usual thing with
> xrdb
> to install the resources.
Thanks, I've just reported this (see
https://github.com/ibus/ibus/issues/2484). I'll be sure to follow
those instructions too if I still get issues with XIM.
I've actually removed IBus now as it's not really relevant to me any
more, so I'm hoping that will resolve the issue. I'll keep a close eye
on things for the rest of the day and I'll report back to confirm.
Kind regards,
--
Simon Pugnet
https://www.polaris64.net/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-06 14:57 ` Simon Pugnet
@ 2023-03-08 14:37 ` Simon Pugnet
2023-03-08 14:59 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Simon Pugnet @ 2023-03-08 14:37 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, 61940
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
Simon Pugnet <simon@polaris64.net> writes:
> Po Lu <luangruo@yahoo.com> writes:
>
>> Simon Pugnet <simon@polaris64.net> writes:
>>
>>> So to summarise, I am getting these issues in Emacs while IBus is
>>> being used as my input method. The IBus crash seems to cause Emacs
>>> to
>>> hang. Once IBus is no longer running Emacs appears to run normally
>>> again. So it looks like this might be an IBus issue rather than an
>>> Emacs issue, but that's just my best guess from the above.
>>
>> Please report this to the I-Bus developers. As for the Xlib
>> lock-up,
>> complain to Fujitsu, who wrote the present XIM implementation in
>> Xlib.
>>
>> To not use XIM, place:
>>
>> Emacs.useXIM: false
>>
>> in your ~/.Xresources or ~/.Xdefaults, and do the usual thing with
>> xrdb
>> to install the resources.
>
> Thanks, I've just reported this (see
> https://github.com/ibus/ibus/issues/2484). I'll be sure to follow
> those instructions too if I still get issues with XIM.
>
> I've actually removed IBus now as it's not really relevant to me any
> more, so I'm hoping that will resolve the issue. I'll keep a close
> eye
> on things for the rest of the day and I'll report back to confirm.
Just to follow up, I haven't noticed any jumbled inputs or Emacs hangs
since removing IBus so I'm pretty confident that this was the cause.
In that case feel free to close this bug if you also agree.
Kind regards,
--
Simon Pugnet
https://www.polaris64.net/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers
2023-03-08 14:37 ` Simon Pugnet
@ 2023-03-08 14:59 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2023-03-08 14:59 UTC (permalink / raw)
To: Simon Pugnet; +Cc: luangruo, 61940-done
> From: Simon Pugnet <simon@polaris64.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 61940@debbugs.gnu.org
> Date: Wed, 08 Mar 2023 14:37:40 +0000
>
> Simon Pugnet <simon@polaris64.net> writes:
>
> > Po Lu <luangruo@yahoo.com> writes:
> >
> >> Simon Pugnet <simon@polaris64.net> writes:
> >>
> >>> So to summarise, I am getting these issues in Emacs while IBus is
> >>> being used as my input method. The IBus crash seems to cause Emacs
> >>> to
> >>> hang. Once IBus is no longer running Emacs appears to run normally
> >>> again. So it looks like this might be an IBus issue rather than an
> >>> Emacs issue, but that's just my best guess from the above.
> >>
> >> Please report this to the I-Bus developers. As for the Xlib
> >> lock-up,
> >> complain to Fujitsu, who wrote the present XIM implementation in
> >> Xlib.
> >>
> >> To not use XIM, place:
> >>
> >> Emacs.useXIM: false
> >>
> >> in your ~/.Xresources or ~/.Xdefaults, and do the usual thing with
> >> xrdb
> >> to install the resources.
> >
> > Thanks, I've just reported this (see
> > https://github.com/ibus/ibus/issues/2484). I'll be sure to follow
> > those instructions too if I still get issues with XIM.
> >
> > I've actually removed IBus now as it's not really relevant to me any
> > more, so I'm hoping that will resolve the issue. I'll keep a close
> > eye
> > on things for the rest of the day and I'll report back to confirm.
>
> Just to follow up, I haven't noticed any jumbled inputs or Emacs hangs
> since removing IBus so I'm pretty confident that this was the cause.
> In that case feel free to close this bug if you also agree.
Thanks, done.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-03-08 14:59 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-03 13:08 bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Simon Pugnet
2023-03-03 16:32 ` Eli Zaretskii
2023-03-03 16:38 ` Simon Pugnet
2023-03-03 18:26 ` Eli Zaretskii
2023-03-06 11:53 ` Simon Pugnet
2023-03-06 12:21 ` Eli Zaretskii
2023-03-06 12:43 ` Simon Pugnet
2023-03-06 13:34 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 14:57 ` Simon Pugnet
2023-03-08 14:37 ` Simon Pugnet
2023-03-08 14:59 ` Eli Zaretskii
2023-03-06 13:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 13:19 ` Simon Pugnet
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).