Package: emacs;
Reported by: Simon Pugnet <simon <at> polaris64.net>
Date: Fri, 3 Mar 2023 15:58:01 UTC
Severity: normal
Found in version 29.0.60
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61940 in the body.
You can then email your comments to 61940 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Fri, 03 Mar 2023 15:58:02 GMT) Full text and rfc822 format available.Simon Pugnet <simon <at> polaris64.net>:bug-gnu-emacs <at> gnu.org.
(Fri, 03 Mar 2023 15:58:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: bug-gnu-emacs <at> gnu.org Subject: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Fri, 03 Mar 2023 13:08:42 +0000 (2 hours, 47 minutes, 40 seconds ago)
[[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 <at> entry=0x55bdbafdfe00, event=event <at> entry=0x7ffefbd49710, finish=finish <at> 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 <at> entry=0x7ffefbd51220, to_charpos=to_charpos <at> entry=23582, to_x=to_x <at> entry=-1, op=op <at> entry=MOVE_TO_POS) at xdisp.c:9740 #32 0x000055bdb98c5a90 in move_it_to (it=it <at> entry=0x7ffefbd51220, to_charpos=to_charpos <at> entry=23582, to_x=to_x <at> entry=-1, to_y=<optimized out>, to_vpos=to_vpos <at> entry=-1, op=op <at> 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 <at> entry=0x7ffefbd54e10) at xdisp.c:24196 #35 0x000055bdb98cb468 in display_line (it=it <at> entry=0x7ffefbd54e10, cursor_vpos=cursor_vpos <at> entry=26) at xdisp.c:24646 #36 0x000055bdb98ce0e8 in try_window (window=window <at> entry=0x55bdbb0bd075, pos=..., flags=flags <at> entry=1) at xdisp.c:20576 #37 0x000055bdb98ed238 in redisplay_window (window=0x55bdbb0bd075, just_this_one_p=just_this_one_p <at> entry=false) at xdisp.c:19960 #38 0x000055bdb98efa1b in redisplay_window_0 (window=window <at> entry=0x55bdbb0bd075) at xdisp.c:17446 #39 0x000055bdb9a44ad4 in internal_condition_case_1 (bfun=bfun <at> entry=0x55bdb98ef9f0 <redisplay_window_0>, arg=arg <at> entry=0x55bdbb0bd075, handlers=<optimized out>, hfun=hfun <at> 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 <at> entry=0x55bdbff8db73, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7ffefbd5a35b, end_time=end_time <at> entry=0x0) at keyboard.c:2627 #44 0x000055bdb99c6db3 in read_key_sequence (keybuf=keybuf <at> entry=0x7ffefbd5a490, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false) at keyboard.c:10074 #45 0x000055bdb99c8c75 in command_loop_1 () at keyboard.c:1375 #46 0x000055bdb9a44a47 in internal_condition_case (bfun=bfun <at> entry=0x55bdb99c8ab0 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x55bdb99bbac0 <cmd_error>) at eval.c:1474 #47 0x000055bdb99b44d6 in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1124 #48 0x000055bdb9a449a1 in internal_catch (tag=tag <at> entry=0x10050, func=func <at> entry=0x55bdb99b44b0 <command_loop_2>, arg=arg <at> 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]]
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Fri, 03 Mar 2023 16:33:01 GMT) Full text and rfc822 format available.Message #8 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Simon Pugnet <simon <at> polaris64.net> Cc: 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Fri, 03 Mar 2023 18:32:03 +0200
> Resent-To: bug-gnu-emacs <at> gnu.org > From: Simon Pugnet <simon <at> 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.
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Fri, 03 Mar 2023 16:44:03 GMT) Full text and rfc822 format available.Message #11 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Fri, 03 Mar 2023 16:38:00 +0000
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes: >> Resent-To: bug-gnu-emacs <at> gnu.org >> From: Simon Pugnet <simon <at> 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/
[signature.asc (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Fri, 03 Mar 2023 18:27:02 GMT) Full text and rfc822 format available.Message #14 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Simon Pugnet <simon <at> polaris64.net> Cc: 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Fri, 03 Mar 2023 20:26:23 +0200
> From: Simon Pugnet <simon <at> polaris64.net> > Cc: 61940 <at> 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".
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 12:04:01 GMT) Full text and rfc822 format available.Message #17 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 11:53:27 +0000
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Simon Pugnet <simon <at> polaris64.net> >> Cc: 61940 <at> 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 <at> entry=0x563eb8c67800, event=event <at> entry=0x7ffce40dc7e0, finish=finish <at> 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 <at> 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 <at> entry=2, args=args <at> entry=0x7ffce40dcfc0) at eval.c:2995 #34 0x0000563eb63aace1 in internal_condition_case_n (bfun=0x563eb63ac2c0 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffce40dcfc0, handlers=handlers <at> entry=0x30, hfun=hfun <at> entry=0x563eb621cb60 <safe_eval_handler>) at eval.c:1558 #35 0x0000563eb6207ecb in safe__call (inhibit_quit=inhibit_quit <at> entry=true, nargs=nargs <at> entry=2, func=func <at> entry=0x6930, ap=ap <at> entry=0x7ffce40dd040) at xdisp.c:3024 #36 0x0000563eb6207ff0 in safe__call1 (inhibit_quit=inhibit_quit <at> entry=true, fn=fn <at> 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 <at> entry=0x7ffce40ddb50, depth=15, depth <at> entry=13, field_width=0, precision=precision <at> entry=-101, elt=0x563ebb1208b3, props=props <at> entry=0x7f11e4a9ac13, risky=false) at xdisp.c:27205 #39 0x0000563eb6238b21 in display_mode_element (it=it <at> entry=0x7ffce40ddb50, depth=13, depth <at> entry=12, field_width=field_width <at> entry=-8, precision=precision <at> 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 <at> entry=0x7ffce40ddb50, depth=12, depth <at> entry=10, field_width=-8, precision=precision <at> entry=-100, elt=0x563ebb120813, props=props <at> entry=0x7f11e4a9ac13, risky=false) at xdisp.c:27228 #41 0x0000563eb6238b21 in display_mode_element (it=it <at> entry=0x7ffce40ddb50, depth=10, depth <at> entry=7, field_width=0, precision=precision <at> entry=-92, elt=0x563ebb120e13, props=props <at> entry=0x7f11e4a9ac13, risky=<optimized out>) at /storage/Work/personal/emacs/src/lisp.h:754 #42 0x0000563eb6238b21 in display_mode_element (it=it <at> entry=0x7ffce40ddb50, depth=7, depth <at> entry=5, field_width=0, precision=precision <at> entry=-80, elt=0x563ebb405ed3, props=props <at> entry=0x7f11e4a9ac13, risky=<optimized out>) at /storage/Work/personal/emacs/src/lisp.h:754 #43 0x0000563eb6238b21 in display_mode_element (it=it <at> entry=0x7ffce40ddb50, depth=5, depth <at> entry=4, field_width=field_width <at> entry=0, precision=precision <at> 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 <at> entry=0x7ffce40ddb50, depth=4, depth <at> entry=3, field_width=0, precision=precision <at> entry=-80, elt=0x7f11e4a9abf3, props=props <at> entry=0x0, risky=false) at xdisp.c:27228 #45 0x0000563eb6238b21 in display_mode_element (it=it <at> entry=0x7ffce40ddb50, depth=3, depth <at> entry=1, field_width=0, precision=precision <at> entry=-76, elt=0x7f11e4a9a8ab, props=props <at> entry=0x0, risky=<optimized out>) at /storage/Work/personal/emacs/src/lisp.h:754 #46 0x0000563eb6238b21 in display_mode_element (it=it <at> entry=0x7ffce40ddb50, depth=1, depth <at> entry=0, field_width=field_width <at> entry=0, precision=precision <at> entry=0, elt=0x7f11e470fadb, elt <at> entry=0x7f11e470fa4b, props=props <at> entry=0x0, risky=<optimized out>) at /storage/Work/personal/emacs/src/lisp.h:754 #47 0x0000563eb623a620 in display_mode_line (w=w <at> entry=0x563ec43bdc60, face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x7f11e470fa4b) at xdisp.c:26717 #48 0x0000563eb623c8ad in display_mode_lines (w=w <at> entry=0x563ec43bdc60) at xdisp.c:26630 #49 0x0000563eb6251d39 in redisplay_window (window=0x563ec43bdc65, just_this_one_p=just_this_one_p <at> entry=false) at xdisp.c:20364 #50 0x0000563eb6255a1b in redisplay_window_0 (window=window <at> entry=0x563ec43bdc65) at xdisp.c:17446 #51 0x0000563eb63aaad4 in internal_condition_case_1 (bfun=bfun <at> entry=0x563eb62559f0 <redisplay_window_0>, arg=arg <at> entry=0x563ec43bdc65, handlers=<optimized out>, hfun=hfun <at> 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 <at> entry=0x563ec421b423, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7ffce40e30db, end_time=end_time <at> entry=0x0) at keyboard.c:2627 #56 0x0000563eb632cdb3 in read_key_sequence (keybuf=keybuf <at> entry=0x7ffce40e3210, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false) at keyboard.c:10074 #57 0x0000563eb632ec75 in command_loop_1 () at keyboard.c:1375 #58 0x0000563eb63aaa47 in internal_condition_case (bfun=bfun <at> entry=0x563eb632eab0 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x563eb6321ac0 <cmd_error>) at eval.c:1474 #59 0x0000563eb631a4d6 in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1124 #60 0x0000563eb63aa9a1 in internal_catch (tag=tag <at> entry=0x10050, func=func <at> entry=0x563eb631a4b0 <command_loop_2>, arg=arg <at> 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/
[signature.asc (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 12:22:01 GMT) Full text and rfc822 format available.Message #20 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Simon Pugnet <simon <at> polaris64.net>, Po Lu <luangruo <at> yahoo.com> Cc: 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 14:21:18 +0200
> From: Simon Pugnet <simon <at> polaris64.net> > Cc: 61940 <at> 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 <at> entry=0x563eb8c67800, > event=event <at> entry=0x7ffce40dc7e0, finish=finish <at> 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.
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 12:53:01 GMT) Full text and rfc822 format available.Message #23 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Po Lu <luangruo <at> yahoo.com>, 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 12:43:56 +0000
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Simon Pugnet <simon <at> polaris64.net>
>> Cc: 61940 <at> 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 <at> 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 <at> 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 <at> entry=6, no_tid=no_tid <at> 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 <at> entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007f8b6115853d in __GI_abort () at abort.c:79
#4 0x00007f8b6115929e in __libc_message (fmt=fmt <at> entry=0x7f8b612d077e
"%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x00007f8b611c7657 in malloc_printerr
(str=str <at> 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 <at> entry=0) at malloc.c:4525
#7 0x00007f8b611cbe63 in __GI___libc_free
(mem=mem <at> entry=0x557071d50db0) at malloc.c:3367
#8 0x00007f8b6135f94e in XFree (data=data <at> 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 <at> entry=0x557071e82e50, connect_id=4,
p=p <at> entry=0x557071db6ab0 ">", delete=delete <at> 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/
[signature.asc (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 13:07:01 GMT) Full text and rfc822 format available.Message #26 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 61940 <at> debbugs.gnu.org, Simon Pugnet <simon <at> polaris64.net> Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 21:05:54 +0800
Eli Zaretskii <eliz <at> 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 <at> entry=0x563eb8c67800, >> event=event <at> entry=0x7ffce40dc7e0, finish=finish <at> 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.
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 13:21:01 GMT) Full text and rfc822 format available.Message #29 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: Po Lu <luangruo <at> yahoo.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 13:19:27 +0000
[Message part 1 (text/plain, inline)]
Po Lu <luangruo <at> yahoo.com> writes: > Eli Zaretskii <eliz <at> 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/
[signature.asc (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 13:35:01 GMT) Full text and rfc822 format available.Message #32 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Simon Pugnet <simon <at> polaris64.net> Cc: Eli Zaretskii <eliz <at> gnu.org>, 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 21:34:06 +0800
Simon Pugnet <simon <at> polaris64.net> writes: > Eli Zaretskii <eliz <at> gnu.org> writes: > >>> From: Simon Pugnet <simon <at> polaris64.net> >>> Cc: 61940 <at> 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 <at> 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 <at> 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 <at> entry=6, no_tid=no_tid <at> 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 <at> entry=6) at > ../sysdeps/posix/raise.c:26 > #3 0x00007f8b6115853d in __GI_abort () at abort.c:79 > #4 0x00007f8b6115929e in __libc_message (fmt=fmt <at> entry=0x7f8b612d077e > "%s\n") at ../sysdeps/posix/libc_fatal.c:150 > #5 0x00007f8b611c7657 in malloc_printerr > (str=str <at> 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 <at> entry=0) at malloc.c:4525 > #7 0x00007f8b611cbe63 in __GI___libc_free > (mem=mem <at> entry=0x557071d50db0) at malloc.c:3367 > #8 0x00007f8b6135f94e in XFree (data=data <at> 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 <at> entry=0x557071e82e50, connect_id=4, > p=p <at> entry=0x557071db6ab0 ">", delete=delete <at> 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.
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Mon, 06 Mar 2023 15:02:02 GMT) Full text and rfc822 format available.Message #35 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: Po Lu <luangruo <at> yahoo.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Mon, 06 Mar 2023 14:57:12 +0000
[Message part 1 (text/plain, inline)]
Po Lu <luangruo <at> yahoo.com> writes: > Simon Pugnet <simon <at> 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/
[signature.asc (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org:bug#61940; Package emacs.
(Wed, 08 Mar 2023 14:40:02 GMT) Full text and rfc822 format available.Message #38 received at 61940 <at> debbugs.gnu.org (full text, mbox):
From: Simon Pugnet <simon <at> polaris64.net> To: Po Lu <luangruo <at> yahoo.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 61940 <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Wed, 08 Mar 2023 14:37:40 +0000
[Message part 1 (text/plain, inline)]
Simon Pugnet <simon <at> polaris64.net> writes: > Po Lu <luangruo <at> yahoo.com> writes: > >> Simon Pugnet <simon <at> 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/
[signature.asc (application/pgp-signature, inline)]
Eli Zaretskii <eliz <at> gnu.org>:Simon Pugnet <simon <at> polaris64.net>:Message #43 received at 61940-done <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Simon Pugnet <simon <at> polaris64.net> Cc: luangruo <at> yahoo.com, 61940-done <at> debbugs.gnu.org Subject: Re: bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Date: Wed, 08 Mar 2023 16:59:59 +0200
> From: Simon Pugnet <simon <at> polaris64.net> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 61940 <at> debbugs.gnu.org > Date: Wed, 08 Mar 2023 14:37:40 +0000 > > Simon Pugnet <simon <at> polaris64.net> writes: > > > Po Lu <luangruo <at> yahoo.com> writes: > > > >> Simon Pugnet <simon <at> 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.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Thu, 06 Apr 2023 11:24:08 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.