From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 02 23:32:33 2025 Received: (at submit) by debbugs.gnu.org; 3 Mar 2025 04:32:33 +0000 Received: from localhost ([127.0.0.1]:42411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toxTi-0004kY-C8 for submit@debbugs.gnu.org; Sun, 02 Mar 2025 23:32:33 -0500 Received: from lists.gnu.org ([2001:470:142::17]:43840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1topzD-0003lm-Ew for submit@debbugs.gnu.org; Sun, 02 Mar 2025 15:32:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1topyz-0006eO-MI for bug-gnu-emacs@gnu.org; Sun, 02 Mar 2025 15:32:18 -0500 Received: from mail.eclipso.de ([217.69.254.104]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1topyv-0007cY-6M for bug-gnu-emacs@gnu.org; Sun, 02 Mar 2025 15:32:17 -0500 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar?= Fuentes DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1740947528; bh=ME9Mgykw3oBUxfOjLkwBUlJb7bnXCG6mMhN+xdZGMC4=; h=From:To:Subject:Date:From; b=RABkdEBXhTCARAtgbDXSnhdmzR0kw6U+hdJVCULbrpHBch3EUGrjgRu8vWqsAtz3l fbAYY6vlJUKMgib3jFwPwfk3vRj1eGY7fyRwpVaij0T03IcuoyOrSOAPvU5okB4EgG ho+MNaEmASJH84YdzEfv/KJlBC/WZwckF9HMRnhQqIqoJGtvDY96Kvr2s6djU3drWg mpCqwnUmjajjGNT4pf+IJL3g34hOcTSocnoYpuRwQgDSPw5qOFvBPxowezI4LrIrPw fBi++ANWNdnl4+asxQ7xbo8/0oEZ9MmSkKct+B1iwiwlUxSnKqJVhWAFqnO5Wv7Y9A 9PLNR26IMmqbg== To: bug-gnu-emacs@gnu.org Subject: 31.0.50; igc: crash X-Debbugs-Cc: Date: Sun, 02 Mar 2025 21:32:07 +0100 Message-ID: <87ikor9nso.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.69.254.104; envelope-from=oscarfv@eclipso.eu; helo=mail.eclipso.de X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 02 Mar 2025 23:32:18 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Emacs just crashed on a session started more than a week ago, IIRC. The following backtrace is from the core dump. Sorry for not being more helpful. #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007f487751de2f in __pthread_kill_internal (threadid=, signo=6) at ./nptl/pthread_kill.c:78 #2 0x00007f48774c9d02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x0000556e0ead9d68 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ../../emacs/src/emacs.c:463 #4 0x0000556e0ed16d73 in set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1023 #5 set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1002 #6 igc_assert_fail (file=, line=, msg=) at ../../emacs/src/igc.c:306 #7 0x0000556e0edd0c10 in shieldFlushEntries () #8 0x0000556e0edd1b89 in ShieldLeave () #9 0x0000556e0edd1d9e in ArenaLeave () #10 0x0000556e0eddbd31 in mps_ap_fill () #11 0x0000556e0ed164d6 in alloc_impl (size=size@entry=88, type=type@entry=IGC_OBJ_VECTOR, ap=0x7f4868001900) at ../../emacs/src/igc.c:4095 #12 0x0000556e0ed1afa8 in alloc (size=88, type=IGC_OBJ_VECTOR) at ../../emacs/src/igc.c:4008 #13 igc_alloc_pseudovector (nwords_mem=nwords_mem@entry=9, nwords_lisp=nwords_lisp@entry=0, nwords_zero=nwords_zero@entry=0, tag=tag@entry=PVEC_HASH_TABLE) at ../../emacs/src/igc.c:4277 #14 0x0000556e0ec65bae in allocate_pseudovector (memlen=memlen@entry=9, lisplen=lisplen@entry=0, zerolen=zerolen@entry=0, tag=tag@entry=PVEC_HASH_TABLE) at ../../emacs/src/alloc.c:3687 #15 0x0000556e0ec938d4 in allocate_hash_table () at ../../emacs/src/fns.c:4842 #16 make_hash_table (test=0x556e0ee7bf80 , size=2, weak=) at ../../emacs/src/fns.c:4897 #17 0x0000556e0ed2a96a in json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1608 #18 json_parse_value (parser=0x7ffd3b15cdd0, c=) at ../../emacs/src/json.c:1655 #19 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1522 #20 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554 #21 json_parse_value (parser=0x7ffd3b15cdd0, c=) at ../../emacs/src/json.c:1655 #22 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454 #23 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657 #24 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1522 #25 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554 #26 json_parse_value (parser=0x7ffd3b15cdd0, c=) at ../../emacs/src/json.c:1655 #27 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454 #28 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657 #29 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1522 #30 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554 #31 json_parse_value (parser=0x7ffd3b15cdd0, c=) at ../../emacs/src/json.c:1655 #32 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454 #33 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657 #34 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1522 #35 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554 #36 json_parse_value (parser=0x7ffd3b15cdd0, c=) at ../../emacs/src/json.c:1655 #37 0x0000556e0ed2aef5 in json_parse (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1705 #38 Fjson_parse_buffer (nargs=, args=) at ../../emacs/src/json.c:1812 #39 0x0000556e0ecd9cba in exec_byte_code (fun=, args_template=, nargs=, args=) at ../../emacs/src/lisp.h:2290 #40 0x0000556e0ec8d858 in Ffuncall (nargs=nargs@entry=3, args=0x7ffd3b15d3d0) at ../../emacs/src/eval.c:3115 #41 0x0000556e0ec8dbe4 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd3b15d460) at ../../emacs/src/eval.c:2787 #42 0x0000556e0ec8df63 in apply1 (fn=, arg=) at ../../emacs/src/eval.c:3003 #43 0x0000556e0ec88fa2 in internal_condition_case_1 (bfun=bfun@entry=0x556e0ece67b0 , arg=0x7f4767c4805b, handlers=handlers@entry=0xa8, hfun=hfun@entry=0x556e0ece66f0 ) at ../../emacs/src/eval.c:1650 #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output (p=, chars=0x556e40d23290 ",{\"detail\":\"void (lxw_workbook *, decltype(lxw_workbook::options))\",\"kind\":6,\"name\":\"w\",\"range\":{\"end\":{\"character\":57,\"line\":12784},\"start\":{\"character\":0,\"line\":12784}},\"selectionRange\":{\"end\":{\"cha"..., nbytes=335897, coding=0x556e2eba74b0) at ../../emacs/src/process.c:6523 #45 read_process_output (proc=proc@entry=0x7f4761f7966d, channel=channel@entry=25) at ../../emacs/src/process.c:6291 #46 0x0000556e0ecf0c8b in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at ../../emacs/src/process.c:5972 #47 0x0000556e0ec06a2f in kbd_buffer_get_event (kbp=, used_mouse_menu=, end_time=) at ../../emacs/src/keyboard.c:4115 #48 read_event_from_main_queue (end_time=end_time@entry=0x0, local_getcjmp=local_getcjmp@entry=0x7ffd3b15dd20, used_mouse_menu=used_mouse_menu@entry=0x7ffd3b15e00b) at ../../emacs/src/keyboard.c:2336 #49 0x0000556e0ec0c5b6 in read_decoded_event_from_main_queue (end_time=, local_getcjmp=, prev_event=, used_mouse_menu=) at ../../emacs/src/keyboard.c:2399 #50 read_char (commandflag=1, map=map@entry=0x7f4766b23feb, prev_event=0x0, used_mouse_menu=used_mouse_menu@entry=0x7ffd3b15e00b, end_time=end_time@entry=0x0) at ../../emacs/src/keyboard.c:3031 #51 0x0000556e0ec0f651 in read_key_sequence (keybuf=keybuf@entry=0x7ffd3b15e140, 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, disable_text_conversion_p=false) at ../../emacs/src/keyboard.c:10790 #52 0x0000556e0ec114d8 in command_loop_1 () at ../../emacs/src/keyboard.c:1435 #53 0x0000556e0ec88f26 in internal_condition_case (bfun=bfun@entry=0x556e0ec11320 , handlers=handlers@entry=0xa8, hfun=hfun@entry=0x556e0ec04560 ) at ../../emacs/src/eval.c:1626 #54 0x0000556e0ebfc43e in command_loop_2 (handlers=handlers@entry=0xa8) at ../../emacs/src/keyboard.c:1174 #55 0x0000556e0ec88e52 in internal_catch (tag=tag@entry=0x14dd0, func=func@entry=0x556e0ebfc410 , arg=arg@entry=0xa8) at ../../emacs/src/eval.c:1305 #56 0x0000556e0ebfc3d3 in command_loop () at ../../emacs/src/keyboard.c:1152 #57 0x0000556e0ec040d6 in recursive_edit_1 () at ../../emacs/src/keyboard.c:760 #58 0x0000556e0ec04488 in Frecursive_edit () at ../../emacs/src/keyboard.c:843 #59 0x0000556e0eae3296 in main (argc=, argv=0x7ffd3b15e5d8) at ../../emacs/src/emacs.c:2580 (gdb) In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.2) of 2025-02-13 built on zen Repository revision: 4b28c41c4f2b43add865f9a8727879cb53dad107 Repository branch: feature/igc Windowing system distributor 'The X.Org Foundation', version 11.0.12101015 System Description: Debian GNU/Linux trixie/sid Configured using: 'configure CPPFLAGS=-I/home/oscar/dev/include/mps LDFLAGS=-L/home/oscar/dev/other/mps/code --with-native-compilation --with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick --with-mps=yes' Configured features: CAIRO FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBOTF LIBSELINUX LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XAW3D XDBE XIM XPM LUCID ZLIB Important settings: value of $LANG: C locale-coding-system: nil Major mode: Lisp Interaction Minor modes in effect: xterm-mouse-mode: t treemacs-filewatch-mode: t treemacs-follow-mode: t treemacs-git-mode: t treemacs-fringe-indicator-mode: t org-roam-db-autosync-mode: t fancy-compilation-mode: t global-git-commit-mode: t pulsar-global-mode: t pulsar-mode: t evil-owl-mode: t evil-paredit-mode: t evil-local-mode: t key-chord-mode: t paredit-mode: t server-mode: t display-fill-column-indicator-mode: t vertico-multiform-mode: t marginalia-mode: t vertico-mode: t which-key-mode: t global-anzu-mode: t anzu-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t minibuffer-regexp-mode: t column-number-mode: t line-number-mode: t indent-tabs-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/oscar/elisp/singles/flx hides /home/oscar/.emacs.d/elpa/flx-20240205.356/flx /home/oscar/elisp/magit/lisp/magit-section hides /home/oscar/.emacs.d/elpa/magit-section-20250301.1617/magit-section /home/oscar/elisp/singles/which-key hides /home/oscar/dev/emacs/emacs/lisp/which-key Features: (shadow sort mail-extr emacsbug vertico-directory help-fns radix-tree mule-util fussy xt-mouse term/xterm xterm meteo-radar lsp-dart lsp-dart-commands lsp-dart-flutter-widget-guide lsp-dart-flutter-fringe-colors lsp-dart-flutter-colors lsp-dart-outline lsp-dart-code-lens lsp-lens lsp-dart-test-tree lsp-treemacs lsp-treemacs-generic lsp-treemacs-themes treemacs-treelib treemacs treemacs-header-line treemacs-compatibility treemacs-mode treemacs-bookmarks treemacs-tags treemacs-interface treemacs-persistence treemacs-filewatch-mode treemacs-follow-mode treemacs-rendering treemacs-annotations treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals treemacs-fringe-indicator treemacs-faces treemacs-icons treemacs-scope treemacs-themes treemacs-core-utils pfuture hl-line treemacs-logging treemacs-customization treemacs-macros lsp-dart-test-output lsp-dart-test-support lsp-dart-dap lsp-dart-devtools lsp-dart-flutter-daemon jsonrpc dap-utils dom xml dap-mode dap-tasks dap-launch lsp-docker yaml posframe dap-overlays lsp-dart-closing-labels lsp-dart-utils lsp-dart-protocol lsp-mode lsp-protocol tree-widget spinner network-stream nsm markdown-mode lv f ewoc flymake flycheck lp0-ts-mode lp0-mode symbol-overlay company-ctags find-file company-fuzzy ht company aggressive-indent deft orgit emacsql-sqlite-builtin sqlite org-roam-migrate org-roam-log org-roam-mode org-roam-capture org-roam-id org-roam-node org-roam-db org-roam-utils org-roam-compat org-roam org-attach emacsql-sqlite emacsql emacsql-compiler org-noter org-element org-persist org-id org-element-ast inline avl-tree org-protocol org-capture org-refile org-crypt org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie treesit executable ob-comint org-pcomplete org-list org-footnote org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval org-cycle org-table org-keys oc org-loaddefs find-func etags-select etags fileloop generator xref project ol org-fold org-fold-core org-compat org-version org-macs fancy-compilation ffap magit-bookmark bookmark git-rebase magit-extras magit-sparse-checkout magit-gitignore magit-ediff ediff magit-subtree magit-patch magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode diff git-commit magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell pcomplete magit-mode transient magit-git magit-base which-func imenu vc-git files-x vc-dispatcher magit-section benchmark cursor-sensor crm pulsar pulse color evil-owl format-spec buffer-flip evil-paredit evil-anzu evil evil-keybindings evil-integration evil-maps evil-commands reveal evil-jumps evil-command-window evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core evil-common rect evil-vars mini-echo mini-echo-segments let-alist hide-mode-line face-remap wgrep grep ag vc-svn compile comint ansi-osc ansi-color find-dired s dash key-chord comp comp-cstr warnings comp-run comp-common cmake-mode rx paredit-menu paredit edmacro kmacro server yasnippet lisp-mnt cl-extra help-mode psvn wid-edit log-edit message sendmail yank-media puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log diff-mode track-changes pp elp ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util dired dired-loaddefs display-fill-column-indicator vertico-multiform marginalia vertico flx-rs-core flx-rs flx goto-chg avy ring highlight-parentheses ws-butler which-key diminish cl anzu easy-mmode thingatpt tmr pcase compat solar cal-dst cal-menu calendar cal-loaddefs finder-inf advice disp-table company-posframe-autoloads company-autoloads consult-flycheck-autoloads consult-lsp-autoloads consult-org-roam-autoloads deadgrep-autoloads eat-autoloads ellama-autoloads embark-consult-autoloads consult-autoloads embark-autoloads flutter-autoloads flycheck-autoloads fussy-autoloads flx-autoloads groovy-mode-autoloads llm-autoloads lsp-dart-autoloads dart-mode-autoloads dap-mode-autoloads bui-autoloads lsp-docker-autoloads lsp-treemacs-autoloads lsp-ui-autoloads lsp-mode-autoloads f-autoloads marginalia-autoloads markdown-mode-autoloads org-roam-autoloads magit-section-autoloads llama-autoloads emacsql-autoloads plz-event-source-autoloads plz-media-type-autoloads plz-autoloads pomm-autoloads alert-autoloads log4e-autoloads gntp-autoloads shell-maker-autoloads spinner-autoloads symbol-overlay-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads avy-autoloads s-autoloads info dash-autoloads vertico-autoloads wgrep-ag-autoloads wgrep-deadgrep-autoloads wgrep-autoloads yaml-autoloads package browse-url xdg url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib 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 touch-screen 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 inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit x multi-tty move-toolbar make-network-process tty-child-frames native-compile mps emacs) _________________________________________________________________ ________________________________________________________ Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 06:38:23 2025 Received: (at submit) by debbugs.gnu.org; 3 Mar 2025 11:38:23 +0000 Received: from localhost ([127.0.0.1]:45426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp47r-0008P1-1q for submit@debbugs.gnu.org; Mon, 03 Mar 2025 06:38:23 -0500 Received: from lists.gnu.org ([2001:470:142::17]:39918) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp47o-0008OZ-1Q for submit@debbugs.gnu.org; Mon, 03 Mar 2025 06:38:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp47f-00028B-VI for bug-gnu-emacs@gnu.org; Mon, 03 Mar 2025 06:38:11 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp47d-0000kk-1P for bug-gnu-emacs@gnu.org; Mon, 03 Mar 2025 06:38:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741001886; x=1741261086; bh=6skkg803tvDKKv4QZgNGBq9JJJK4GH0vijCmP8RsVig=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=cAmemr/un/3EmdtvpsvhBYHu1qhfw4iUUIUsSqwD7/xqKQmN0djkzripQzuSC/LQY cb+uPT2gwxCHSEF67CHGOT9N55/i/t9U4CYRIWz4gzEL58hLziXLJZ7CwJWFPrj1eL l5McHRNbkAg64zVo2Ugbnnwdw7wL5EsLcTGg3fBg6bNuC3onBdHm+rjBh7Csfbg845 6AJXsYxpf4rDszkOe+0+YyKEYPFvdsDv4w7sEwZVKrt1P8PzfHxrtUVN4KpEVQ0jJR WzXMY6EH2b5oOzMuWwYzVmt8gh4I9sWF0M3fuHzBp5um1tta1ehvNxDArkGksTlNkw inbTT0Z1LVocg== Date: Mon, 03 Mar 2025 11:38:01 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes_via_Bug_reports_for_GNU_Emacs=2C_the_Swiss_army_knife_of_text_editors?= From: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash Message-ID: <87h64axs3p.fsf@protonmail.com> In-Reply-To: <87ikor9nso.fsf@telefonica.net> References: <87ikor9nso.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0c11d7a0db213f088c512361ae2e97d6ee8241e4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=79.135.106.28; envelope-from=pipcet@protonmail.com; helo=mail-10628.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) =C3=93scar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of = text editors" writes: > Emacs just crashed on a session started more than a week ago, IIRC. > > The following backtrace is from the core dump. Sorry for not being more > helpful. Can you try generating a full backtrace ("bt full" should work on the core dump, too)? > #0 __pthread_kill_implementation (threadid=3D, signo=3Dsi= gno@entry=3D6, no_tid=3Dno_tid@entry=3D0) > at ./nptl/pthread_kill.c:44 > #1 0x00007f487751de2f in __pthread_kill_internal (threadid=3D, signo=3D6) > at ./nptl/pthread_kill.c:78 > #2 0x00007f48774c9d02 in __GI_raise (sig=3Dsig@entry=3D6) at ../sysdeps/= posix/raise.c:26 > #3 0x0000556e0ead9d68 in terminate_due_to_signal > (sig=3Dsig@entry=3D6, backtrace_limit=3Dbacktrace_limit@entry=3D21474= 83647) at ../../emacs/src/emacs.c:463 > #4 0x0000556e0ed16d73 in set_state (state=3DIGC_STATE_DEAD) at ../../ema= cs/src/igc.c:1023 > #5 set_state (state=3DIGC_STATE_DEAD) at ../../emacs/src/igc.c:1002 > #6 igc_assert_fail (file=3D, line=3D, msg= =3D) > at ../../emacs/src/igc.c:306 > #7 0x0000556e0edd0c10 in shieldFlushEntries () shieldFlushEntries contains several asserts. Can you disassemble the function shieldFlushEntries to see which one we hit? (gdb: "disass/s shieldFlushEntries"). > #8 0x0000556e0edd1b89 in ShieldLeave () > #9 0x0000556e0edd1d9e in ArenaLeave () > #10 0x0000556e0eddbd31 in mps_ap_fill () > #11 0x0000556e0ed164d6 in alloc_impl > (size=3Dsize@entry=3D88, type=3Dtype@entry=3DIGC_OBJ_VECTOR, ap=3D0x7= f4868001900) at ../../emacs/src/igc.c:4095 > #12 0x0000556e0ed1afa8 in alloc (size=3D88, type=3DIGC_OBJ_VECTOR) at ../= ../emacs/src/igc.c:4008 > #13 igc_alloc_pseudovector > (nwords_mem=3Dnwords_mem@entry=3D9, nwords_lisp=3Dnwords_lisp@entry= =3D0, nwords_zero=3Dnwords_zero@entry=3D0, tag=3Dtag@entry=3DPVEC_HASH_TABL= E) at ../../emacs/src/igc.c:4277 > #14 0x0000556e0ec65bae in allocate_pseudovector > (memlen=3Dmemlen@entry=3D9, lisplen=3Dlisplen@entry=3D0, zerolen=3Dze= rolen@entry=3D0, tag=3Dtag@entry=3DPVEC_HASH_TABLE) at ../../emacs/src/allo= c.c:3687 > #15 0x0000556e0ec938d4 in allocate_hash_table () at ../../emacs/src/fns.c= :4842 > #16 make_hash_table (test=3D0x556e0ee7bf80 , size=3D2, we= ak=3D) > at ../../emacs/src/fns.c:4897 > #17 0x0000556e0ed2a96a in json_parse_object (parser=3D0x7ffd3b15cdd0) at = ../../emacs/src/json.c:1608 > #18 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ..= /../emacs/src/json.c:1655 > #19 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd= 3b15cdd0) > at ../../emacs/src/json.c:1522 > #20 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c= :1554 > #21 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ..= /../emacs/src/json.c:1655 > #22 0x0000556e0ed2a7fa in json_parse_array (parser=3D0x7ffd3b15cdd0) at .= ./../emacs/src/json.c:1454 > #23 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D91) at ../../emacs/src= /json.c:1657 > #24 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd= 3b15cdd0) > at ../../emacs/src/json.c:1522 > #25 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c= :1554 > #26 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ..= /../emacs/src/json.c:1655 > #27 0x0000556e0ed2a7fa in json_parse_array (parser=3D0x7ffd3b15cdd0) at .= ./../emacs/src/json.c:1454 > #28 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D91) at ../../emacs/src= /json.c:1657 > #29 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd= 3b15cdd0) > at ../../emacs/src/json.c:1522 > #30 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c= :1554 > #31 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ..= /../emacs/src/json.c:1655 > #32 0x0000556e0ed2a7fa in json_parse_array (parser=3D0x7ffd3b15cdd0) at .= ./../emacs/src/json.c:1454 > #33 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D91) at ../../emacs/src= /json.c:1657 > #34 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd= 3b15cdd0) > at ../../emacs/src/json.c:1522 > #35 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c= :1554 > #36 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ..= /../emacs/src/json.c:1655 > #37 0x0000556e0ed2aef5 in json_parse (parser=3D0x7ffd3b15cdd0) at ../../e= macs/src/json.c:1705 > #38 Fjson_parse_buffer (nargs=3D, args=3D) = at ../../emacs/src/json.c:1812 > #39 0x0000556e0ecd9cba in exec_byte_code > (fun=3D, args_template=3D, nargs=3D, args=3D) > at ../../emacs/src/lisp.h:2290 > #40 0x0000556e0ec8d858 in Ffuncall (nargs=3Dnargs@entry=3D3, args=3D0x7ff= d3b15d3d0) > at ../../emacs/src/eval.c:3115 > #41 0x0000556e0ec8dbe4 in Fapply (nargs=3Dnargs@entry=3D2, args=3Dargs@en= try=3D0x7ffd3b15d460) > at ../../emacs/src/eval.c:2787 > #42 0x0000556e0ec8df63 in apply1 (fn=3D, arg=3D) at ../../emacs/src/eval.c:3003 > #43 0x0000556e0ec88fa2 in internal_condition_case_1 > (bfun=3Dbfun@entry=3D0x556e0ece67b0 , arg= =3D0x7f4767c4805b, handlers=3Dhandlers@entry=3D0xa8, hfun=3Dhfun@entry=3D0x= 556e0ece66f0 ) at ../../emacs/src/eval.c= :1650 > #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output > (p=3D, chars=3D0x556e40d23290 ",{\"detail\":\"void (lx= w_workbook *, decltype(lxw_workbook::options))\",\"kind\":6,\"name\":\"w\",= \"range\":{\"end\":{\"character\":57,\"line\":12784},\"start\":{\"character= \":0,\"line\":12784}},\"selectionRange\":{\"end\":{\"cha"..., nbytes=3D3358= 97, coding=3D0x556e2eba74b0) 335 KB? That's a lot, so it's likely that the problem was caused in the json code... I'll have a look, particularly at xcdr_addr, which is rarely used in other code. > In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo > version 1.18.2) of 2025-02-13 built on zen > Repository revision: 4b28c41c4f2b43add865f9a8727879cb53dad107 Hmm. That's a bit older, but I don't think this looks like any of the bugs that have been fixed since. Thanks for the report, I'll try stress-testing the JSON code next. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 10:12:52 2025 Received: (at submit) by debbugs.gnu.org; 3 Mar 2025 15:12:52 +0000 Received: from localhost ([127.0.0.1]:49827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp7TO-0002ol-2D for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:12:52 -0500 Received: from lists.gnu.org ([2001:470:142::17]:42526) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp7TJ-0002o8-46 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:12:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp7T2-0002QW-56 for bug-gnu-emacs@gnu.org; Mon, 03 Mar 2025 10:12:30 -0500 Received: from mail.eclipso.de ([217.69.254.104]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp7So-0001Nf-Om for bug-gnu-emacs@gnu.org; Mon, 03 Mar 2025 10:12:26 -0500 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1741014729; bh=df4VKp+5SsN8wwUvohHlZ+TxHERWXHUUACT2YGmWGZk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U6uVbnSt32o0T+eY0K8JUAD1i/3te1E+7oMT68gI7nz9beWnhzliS7PzS2zpL4uyX pufXTmyOiHjiE9B1c5Ft8FfSAp3u04VjkeeRUiUjVfasR/aPgIVM9KwJAzxwFOm5Wg c+X3JvHoMsL2nDzwaPwExJxLH0jB7eUWAepZzkVTPPaOOxd/4g1gJKGiDXKhkEf1qp CLiJhv3EGEZr7VJb7JP7gxFb5PVbkA0rLGxn9E9RYJz6dFTiqb3GR4Kmxw+M59PqaW ThCSSvkfyg87HWhucbfS5AoDZbEhaUxGglKceMKmsyPF4wsJ/eHzzuqitm0JuHUtd3 wokrjWfXbgI7g== To: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash In-Reply-To: <87h64axs3p.fsf@protonmail.com> (Pip Cet's message of "Mon, 03 Mar 2025 11:38:01 +0000") References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> Date: Mon, 03 Mar 2025 16:12:07 +0100 Message-ID: <878qpm9mig.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=217.69.254.104; envelope-from=oscarfv@eclipso.eu; helo=mail.eclipso.de X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Pip Cet writes: > =C3=93scar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife o= f text editors" writes: > >> Emacs just crashed on a session started more than a week ago, IIRC. >> >> The following backtrace is from the core dump. Sorry for not being more >> helpful. > > Can you try generating a full backtrace ("bt full" should work on the > core dump, too)? #0 __pthread_kill_implementation (threadid=3D, signo=3Dsign= o@entry=3D6, no_tid=3Dno_tid@entry=3D0) at ./nptl/pthread_kill.c:44 tid =3D ret =3D 0 pd =3D old_mask =3D {__val =3D {0}} ret =3D #1 0x00007f487751de2f in __pthread_kill_internal (threadid=3D, signo=3D6) at ./nptl/pthread_kill.c:78 #2 0x00007f48774c9d02 in __GI_raise (sig=3Dsig@entry=3D6) at ../sysdeps/po= six/raise.c:26 ret =3D #3 0x0000556e0ead9d68 in terminate_due_to_signal (sig=3Dsig@entry=3D6, backtrace_limit=3Dbacktrace_limit@entry=3D2147483= 647) at ../../emacs/src/emacs.c:463 #4 0x0000556e0ed16d73 in set_state (state=3DIGC_STATE_DEAD) at ../../emacs= /src/igc.c:1023 old_state =3D old_state =3D #5 set_state (state=3DIGC_STATE_DEAD) at ../../emacs/src/igc.c:1002 old_state =3D #6 igc_assert_fail (file=3D, line=3D, msg=3D= ) at ../../emacs/src/igc.c:306 #7 0x0000556e0edd0c10 in shieldFlushEntries () #8 0x0000556e0edd1b89 in ShieldLeave () #9 0x0000556e0edd1d9e in ArenaLeave () #10 0x0000556e0eddbd31 in mps_ap_fill () #11 0x0000556e0ed164d6 in alloc_impl (size=3Dsize@entry=3D88, type=3Dtype@entry=3DIGC_OBJ_VECTOR, ap=3D0x7f4= 868001900) at ../../emacs/src/igc.c:4095 res =3D --Type for more, q to quit, c to continue without paging-- p =3D 0x0 #12 0x0000556e0ed1afa8 in alloc (size=3D88, type=3DIGC_OBJ_VECTOR) at ../..= /emacs/src/igc.c:4008 #13 igc_alloc_pseudovector (nwords_mem=3Dnwords_mem@entry=3D9, nwords_lisp=3Dnwords_lisp@entry=3D0= , nwords_zero=3Dnwords_zero@entry=3D0, tag=3Dtag@entry=3DPVEC_HASH_TABLE) a= t ../../emacs/src/igc.c:4277 client_size =3D 88 v =3D #14 0x0000556e0ec65bae in allocate_pseudovector (memlen=3Dmemlen@entry=3D9, lisplen=3Dlisplen@entry=3D0, zerolen=3Dzero= len@entry=3D0, tag=3Dtag@entry=3DPVEC_HASH_TABLE) at ../../emacs/src/alloc.= c:3687 #15 0x0000556e0ec938d4 in allocate_hash_table () at ../../emacs/src/fns.c:4= 842 #16 make_hash_table (test=3D0x556e0ee7bf80 , size=3D2, weak= =3D) at ../../emacs/src/fns.c:4897 h =3D #17 0x0000556e0ed2a96a in json_parse_object (parser=3D0x7ffd3b15cdd0) at ..= /../emacs/src/json.c:1608 value =3D h =3D c =3D first =3D 4019 result =3D 0x0 c =3D first =3D result =3D cdr =3D key =3D value =3D key =3D --Type for more, q to quit, c to continue without paging-- value =3D nc =3D key =3D value =3D nc =3D value =3D h =3D i =3D hash =3D key =3D value =3D i =3D #18 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ../.= ./emacs/src/json.c:1655 c2 =3D c3 =3D c4 =3D c5 =3D c6 =3D #19 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd3b= 15cdd0) at ../../emacs/src/json.c:1522 c =3D c =3D #20 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c:1= 554 key =3D 0x7f476c1a7d74 value =3D cdr =3D 0x7ffd3b15cab0 c =3D 34 --Type for more, q to quit, c to continue without paging-- first =3D 4011 result =3D 0x0 c =3D first =3D result =3D cdr =3D key =3D value =3D key =3D value =3D nc =3D key =3D value =3D nc =3D value =3D h =3D i =3D hash =3D key =3D value =3D i =3D #21 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ../.= ./emacs/src/json.c:1655 c2 =3D c3 =3D c4 =3D c5 =3D c6 =3D --Type for more, q to quit, c to continue without paging-- #22 0x0000556e0ed2a7fa in json_parse_array (parser=3D0x7ffd3b15cdd0) at ../= ../emacs/src/json.c:1454 element =3D cdr =3D 0x7ffd3b15cb28 c =3D first =3D 4010 result =3D 0x0 c =3D first =3D result =3D cdr =3D element =3D nc =3D number_of_elements =3D i =3D #23 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D91) at ../../emacs/src/j= son.c:1657 c2 =3D c3 =3D c4 =3D c5 =3D c6 =3D #24 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd3b= 15cdd0) at ../../emacs/src/json.c:1522 c =3D c =3D #25 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c:1= 554 key =3D 0x7f476c1a7254 value =3D --Type for more, q to quit, c to continue without paging-- cdr =3D 0x7ffd3b15cb90 c =3D 34 first =3D 4010 result =3D 0x0 c =3D first =3D result =3D cdr =3D key =3D value =3D key =3D value =3D nc =3D key =3D value =3D nc =3D value =3D h =3D i =3D hash =3D key =3D value =3D i =3D #26 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ../.= ./emacs/src/json.c:1655 c2 =3D c3 =3D c4 =3D --Type for more, q to quit, c to continue without paging-- c5 =3D c6 =3D #27 0x0000556e0ed2a7fa in json_parse_array (parser=3D0x7ffd3b15cdd0) at ../= ../emacs/src/json.c:1454 element =3D cdr =3D 0x7ffd3b15cc08 c =3D first =3D 4009 result =3D 0x0 c =3D first =3D result =3D cdr =3D element =3D nc =3D number_of_elements =3D i =3D #28 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D91) at ../../emacs/src/j= son.c:1657 c2 =3D c3 =3D c4 =3D c5 =3D c6 =3D #29 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd3b= 15cdd0) at ../../emacs/src/json.c:1522 c =3D c =3D #30 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c:1= 554 --Type for more, q to quit, c to continue without paging-- key =3D 0x7f476c1a5bcc value =3D cdr =3D 0x7ffd3b15cc70 c =3D 34 first =3D 4009 result =3D 0x0 c =3D first =3D result =3D cdr =3D key =3D value =3D key =3D value =3D nc =3D key =3D value =3D nc =3D value =3D h =3D i =3D hash =3D key =3D value =3D i =3D #31 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ../.= ./emacs/src/json.c:1655 c2 =3D --Type for more, q to quit, c to continue without paging-- c3 =3D c4 =3D c5 =3D c6 =3D #32 0x0000556e0ed2a7fa in json_parse_array (parser=3D0x7ffd3b15cdd0) at ../= ../emacs/src/json.c:1454 element =3D cdr =3D 0x7ffd3b15cce8 c =3D first =3D 4 result =3D 0x0 c =3D first =3D result =3D cdr =3D element =3D nc =3D number_of_elements =3D i =3D #33 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D91) at ../../emacs/src/j= son.c:1657 c2 =3D c3 =3D c4 =3D c5 =3D c6 =3D #34 0x0000556e0ed2a61a in json_parse_object_member_value (parser=3D0x7ffd3b= 15cdd0) at ../../emacs/src/json.c:1522 c =3D --Type for more, q to quit, c to continue without paging-- c =3D #35 json_parse_object (parser=3D0x7ffd3b15cdd0) at ../../emacs/src/json.c:1= 554 key =3D 0x7f4767c488ec value =3D cdr =3D 0x7ffd3b15cd50 c =3D 34 first =3D 0 result =3D 0x0 c =3D first =3D result =3D cdr =3D key =3D value =3D key =3D value =3D nc =3D key =3D value =3D nc =3D value =3D h =3D i =3D hash =3D key =3D value =3D i =3D --Type for more, q to quit, c to continue without paging-- #36 json_parse_value (parser=3D0x7ffd3b15cdd0, c=3D) at ../.= ./emacs/src/json.c:1655 c2 =3D c3 =3D c4 =3D c5 =3D c6 =3D #37 0x0000556e0ed2aef5 in json_parse (parser=3D0x7ffd3b15cdd0) at ../../ema= cs/src/json.c:1705 #38 Fjson_parse_buffer (nargs=3D, args=3D) at= ../../emacs/src/json.c:1812 count =3D {bytes =3D } conf =3D {object_type =3D , array_type =3D , null_object =3D , false_object =3D } p =3D {input_current =3D 0x556e3342596e "}],\"detail\":\"struct\",\= "kind\":23,\"name\":\"ra_struct_0xAB71CCE7u\",\"range\":{\"end\":{\"c= haracter\":62,\"line\":9091},\"start\":{\"character\":0,\"line\":9091}},\"s= electionRange\":{\"end\":{\"character\":10,\"line\":9091"..., input_begin = =3D 0x556e32ee1f60 "{\"id\":17456,\"jsonrpc\":\"2.0\",\"result\":[{\"childr= en\":[{\"detail\":\"lp0::PluginInfoAdder\",\"kind\":13,\"name\":\"ppa8\",\"= range\":{\"end\":{\"character\":33,\"line\":7},\"start\":{\"character\":0,\= "line\":7}},\"selectionRange\":"..., input_end =3D 0x556e33733f5e "", secon= dary_input_begin =3D 0x0, secondary_input_end =3D 0x0, current_line =3D 1, = current_column =3D 5519886, point_of_current_line =3D 0, available_depth = =3D 9993, conf =3D {object_type =3D json_object_hashtable, array_type =3D j= son_array_array, null_object =3D 0x0, false_object =3D 0x0}, additional_byt= es_count =3D 0, internal_object_workspace =3D {0x7f4767c48874, 0x110c2, 0x7= f4767c4889c, 0x7f4767c488c4, 0x7f4767c4972d, 0x7f4767c4c63d, 0x7f4767c4cd4d= , 0x7f4767c4f9c5, 0x7f4767c53005, 0x7f4767c53ef5, 0x7f4767c54df5, 0x7f4767c= 55ce5, 0x7f4767c58bf5, 0x7f4767c59ae5, 0x7f4767c5c76d, 0x7f4767c5dd9d, 0x7f= 4767c60c8d, 0x7f4767c61b7d, 0x7f4767c62a6d, 0x7f4767c6395d, 0x7f4767c6689d,= 0x7f4767c6778d, 0x7f4767c6868d, 0x7f4767c6957d, 0x7f4767c6c48d, 0x7f4767c6= d37d, 0x7f4767c6e26d, 0x7f4767c6f15d, 0x7f4767c7009d, 0x7f4767c70f8d, 0x7f4= 767c71e7d, 0x7f4767c74d7d, 0x7f4767c75c6d, 0x7f4767c76b7d, 0x7f4767c77a6d, = 0x7f4767c7a9ad, 0x7f4767c7b89d, 0x7f4767c7c78d, 0x7f4767c7d67d, 0x7f4767c80= 575, 0x7f4767c81465, 0x7f4767c8237d, 0x7f4767c8326d, 0x7f4767c8615d, 0x7f47= 67c8704d, 0x7f4767c87f3d, 0x7f4767c88e5d, 0x7f4767c89d4d, 0x7f4767c8cc8d, 0= x7f4767c8cd64, 0x7f4767c8d4dd, 0x7f4767c--Type for more, q to quit, c= to continue without paging-- 8d4f4, 0x7f4767c8d51c, 0x7f4767c8d544, 0x56, 0x7f4767c8d56c, 0x7f4767c8d594= , 0x7f4767c8d5bc, 0x7f4767c8d805, 0x7f4767c8d8c4, 0x7f4767c8d93d, 0x7f4767c= 8d9fc, 0x2, 0x21e}, object_workspace =3D 0x556e374c43e0, object_workspace_s= ize =3D 4096, object_workspace_current =3D 4023, internal_byte_workspace = =3D "9091acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options = *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177\000\000\000\00= 0\000\000\000\000\000\000\020\370\302\016nU\000\000\b\000\000\000\000\000\0= 00\000\020\321\025;\375\177\000\000\t\000\000\000\000\000\000\000\310\321\0= 25;\375\177\000\000\000\000\000\000\000\000\000\000\020\370\302\016nU\000\0= 00\b\000\000\000\000\000\000\000p\321\025;\375\177\000\000"..., byte_worksp= ace =3D 0x7ffd3b15d050 "9091acterRange(lxw_chart_options::x_scale) *, const= lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375= \177", byte_workspace_end =3D 0x7ffd3b15d250 "P\320\025;\375\177", byte_wor= kspace_current =3D 0x7ffd3b15d054 "acterRange(lxw_chart_options::x_scale) *= , const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\0= 25;\375\177"} begin =3D end =3D secondary_begin =3D secondary_end =3D result =3D byte =3D position =3D #39 0x0000556e0ecd9cba in exec_byte_code (fun=3D, args_template=3D, nargs=3D, args=3D) at ../../emacs/src/lisp.h:2290 call_nargs =3D 6 call_fun =3D count1 =3D {bytes =3D } val =3D call_args =3D 0x7f486347f078 original_fun =3D 0x29da650d7dc0 --Type for more, q to quit, c to continue without paging-- op =3D 6 type =3D targets =3D {0x556e0eadee50 , 0x556e0ecda0c8 = , 0x556e0ecda0c3 , 0x556e0ecda0be= , 0x556e0ecd9aa3 , 0x556e0ecd9aa3= , 0x556e0ecda080 , 0x556e0ecda042= , 0x556e0ecdc03a , 0x556e0ecdc0= 35 , 0x556e0ecdc030 , 0x556e0ec= dc02b , 0x556e0ecd9add , 0x556e0e= cd9ae0 , 0x556e0ecdc01e , 0x556e0= ecdc03f , 0x556e0ecdbec6 , 0x556= e0ecdbec1 , 0x556e0ecdbebc , 0x55= 6e0ecdbeb7 , 0x556e0ecd9a39 , 0x55= 6e0ecd9a40 , 0x556e0ecdbe9d , 0x55= 6e0ecdbeaa , 0x556e0ecdbe4b , 0x5= 56e0ecdbe46 , 0x556e0ecdbe41 , 0x= 556e0ecdbe3c , 0x556e0ecd9d98 , 0= x556e0ecd9da0 , 0x556e0ecdbe5d , = 0x556e0ecdbe50 , 0x556e0ecdbe1d ,= 0x556e0ecdbe18 , 0x556e0ecdbe13 = , 0x556e0ecdbe0e , 0x556e0ecd9b3d = , 0x556e0ecd9b40 , 0x556e0ecdbe2f = , 0x556e0ecdbe22 , 0x556e0ecdbdef , 0x556e0ecdbdea , 0x556e0ecdbde5 , 0x556e0ecdbde0 , 0x556e0ecd9d4b , 0x556e0ecd9d50 , 0x556e0ecdbe01 , 0x556e0ecdbdf4 , 0x556e0ecdb9fa , 0x556e0ecdba2e , 0x556e0ecdbab0 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0ecdb84e , 0x556e0ecdb7db , 0x556e0ecdb794 , 0x556e0ecdb74d , 0x556e0ecdb708 , 0x556e0ecdbf47 , 0x556e0ecdbf07 , 0x556e0ecdb6d6 , 0x556e0ecdbfa3 , 0x556e0ecdbecb , 0x556e0ecdb696 , 0x556e0ecdb666 , 0x556e0ecdb626 <= exec_byte_code+7526>, 0x556e0ecdb5e9 , 0x556e0ecdb5a8 = for more, q to quit, c to continue without paging-- xec_byte_code+7400>, 0x556e0ecdb532 , 0x556e0ecdb4a7 <= exec_byte_code+7143>, 0x556e0ecdb412 , 0x556e0ecdb3e2 = , 0x556e0ecdb3b2 , 0x556e0ecdb372= , 0x556e0ecdb332 , 0x556e0ecdb2f= 2 , 0x556e0ecdb2ae , 0x556e0ecdb2= 74 , 0x556e0ecdb23a , 0x556e0ecdb= 200 , 0x556e0ecdb15e , 0x556e0ecd= b102 , 0x556e0ecdb0a8 , 0x556e0ec= db04e , 0x556e0ecdaff4 , 0x556e0e= cdaf9a , 0x556e0ecdaf40 , 0x556e0= ecdaee8 , 0x556e0ecdae8b , 0x556e= 0ecdae33 , 0x556e0ecdaddb , 0x556= e0ecdad83 , 0x556e0ecdad2a , 0x55= 6e0ecdac39 , 0x556e0ecd9de9 , 0x5= 56e0ecdac09 , 0x556e0ecdabd4 , 0x= 556e0ecdab44 , 0x556e0ecdaafa , 0= x556e0ecdaaca , 0x556e0ecdaa98 , = 0x556e0ecdaa66 , 0x556e0ecdaa2c ,= 0x556e0ecda9fa , 0x556e0eadee50 , 0x556e0ecda9c8 , 0x556e0ecda996 , 0x556e0ecda964 , 0x556e0ecda932 , 0x556e0ecda900 , 0x556e0ecda8d0 , 0x556e0ecd9de9 , 0x556e0eadee50 , 0x556e0ecda88d , 0x556e0ecda85d , 0x556e0ecda82c , 0x556e0ecda7eb , 0x556e0ecda7aa , 0x556e0ecda779 , 0x556e0ecda748 , 0x556e0ecda707 , 0x556e0ecda6c6 , 0x556e0ecda685 , 0x556e0ecda652 , 0x556e0ecda621 , 0x556e0eadee50 , 0x556e0ecdbbbf , 0x556e0ecdbd6e , 0x556e0ecdbfdf , 0x556e0ecdbd2f , 0x556e0ecdbcf3 , 0x556e0ecdbcb7 , 0x556e0ecdbc1d , 0x556e0ecdbbf8 , 0x556e0ecdbe6a , 0x556e0ecdbb9a , 0x556e0ecdbb37 <= exec_byte_code+8823>, 0x556e0ecdbb02 , 0x556e0ecdbabb = , 0x556e0ecdb9a5 , 0x556e0ecdb961= , 0x556e0ecdb917 , 0x556e0ecdb8a= c , 0x556e0eadee50 , 0x--Type for more, q to quit, c to continue without paging-- 556e0ecda5dc , 0x556e0ecda5ab , 0= x556e0ecda57a , 0x556e0ecda549 , = 0x556e0ecda518 , 0x556e0ecda4d7 ,= 0x556e0ecda496 , 0x556e0ecda455 = , 0x556e0ecda414 , 0x556e0ecda3ad , 0x556e0ecda36c , 0x556e0ecda32b , 0x556e0ecda2fa , 0x556e0ecda2ae , 0x556e0ecda262 , 0x556e0ecda224 , 0x556e0ecda1e6 , 0x556e0ecda1ab , 0x556e0ecdacd2 , 0x556e0ecdac83 , 0x556e0ecda13b , 0x556e0ecda0cd , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0ecdb562 , 0x556e0ecdb1ba , 0x556e0ecdab8e , 0x556e0ecd9ffc , 0x556e0ecd9fb6 , 0x556e0eadee50 , 0x556e0eadee50 , 0x556e0ecd9f7d= , 0x556e0ecd9f19 , 0x556e0eadee5= 0 , 0x556e0eadee50 , 0x556e0ead= ee50 , 0x556e0eadee50 , 0x556e0= eadee50 , 0x556e0eadee50 , 0x55= 6e0eadee50 , 0x556e0eadee50 , 0= x556e0ecd9edf } quitcounter =3D bc =3D 0x556e0ee8a8f8 top =3D 0x7f486347f070 pc =3D bytestr =3D vector =3D maxdepth =3D const_length =3D bytestr_length =3D vectorp =3D 0x7f4761f7f9a8 --Type for more, q to quit, c to continue without paging-- max_stack =3D frame_base =3D fp =3D bytestr_data =3D rest =3D mandatory =3D nonrest =3D pushedargs =3D saved_quitcounter =3D 1 '\001' saved_vectorp =3D 0x7f4761f7f9a8 saved_bytestr_data =3D 0x7f4782ba94e8 "\300\306=C3=A2!\203\020" result =3D #40 0x0000556e0ec8d858 in Ffuncall (nargs=3Dnargs@entry=3D3, args=3D0x7ffd3= b15d3d0) at ../../emacs/src/eval.c:3115 count =3D {bytes =3D } val =3D #41 0x0000556e0ec8dbe4 in Fapply (nargs=3Dnargs@entry=3D2, args=3Dargs@entr= y=3D0x7ffd3b15d460) at ../../emacs/src/eval.c:2787 i =3D funcall_nargs =3D 3 funcall_args =3D spread_arg =3D fun =3D sa_avail =3D sa_count =3D {bytes =3D 352} numargs =3D retval =3D --Type for more, q to quit, c to continue without paging-- #42 0x0000556e0ec8df63 in apply1 (fn=3D, arg=3D) at ../../emacs/src/eval.c:3003 #43 0x0000556e0ec88fa2 in internal_condition_case_1 (bfun=3Dbfun@entry=3D0x556e0ece67b0 , arg=3D0= x7f4767c4805b, handlers=3Dhandlers@entry=3D0xa8, hfun=3Dhfun@entry=3D0x556e= 0ece66f0 ) at ../../emacs/src/eval.c:1650 val =3D c =3D 0x7f4873e850a0 #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output (p=3D, chars=3D0x556e40d23290 ",{\"detail\":\"void (lxw_= workbook *, decltype(lxw_workbook::options))\",\"kind\":6,\"name\":\"w\",\"= range\":{\"end\":{\"character\":57,\"line\":12784},\"start\":{\"character\"= :0,\"line\":12784}},\"selectionRange\":{\"end\":{\"cha"..., nbytes=3D335897= , coding=3D0x556e2eba74b0) at ../../emacs/src/process.c:6523 outstream =3D 0x7f4761f7f1ed text =3D 0x7f4767c48004 outer_running_asynch_code =3D true waiting =3D -1 outstream =3D text =3D outer_running_asynch_code =3D waiting =3D tem =3D #45 read_process_output (proc=3Dproc@entry=3D0x7f4761f7966d, channel=3Dchan= nel@entry=3D25) at ../../emacs/src/process.c:6291 nbytes =3D 335897 p =3D 0x7f4761f79668 coding =3D carryover =3D readmax =3D --Type for more, q to quit, c to continue without paging-- count =3D {bytes =3D } odeactivate =3D 0x0 chars =3D sa_avail =3D sa_count =3D {bytes =3D } #46 0x0000556e0ecf0c8b in wait_reading_process_output (time_limit=3Dtime_limit@entry=3D0, nsecs=3Dnsecs@entry=3D0, read_kbd= =3Dread_kbd@entry=3D-1, do_display=3Dtrue, wait_for_cell=3Dwait_for_cell@en= try=3D0x0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_proc=3D0) at ../../emacs/src/process.c:5972 nread =3D process_skipped =3D wrapped =3D channel_start =3D 26 child_fd =3D last_read_channel =3D 25 channel =3D nfds =3D Available =3D {fds_bits =3D {33554432, 0 }} Writeok =3D {fds_bits =3D {0 }} check_write =3D check_delay =3D no_avail =3D xerrno =3D 11 proc =3D 0x7f4761f7966d timeout =3D {tv_sec =3D 0, tv_nsec =3D 10000000} end_time =3D {tv_sec =3D 0, tv_nsec =3D 139949216517785} timer_delay =3D {tv_sec =3D , tv_nsec =3D } --Type for more, q to quit, c to continue without paging-- got_output_end_time =3D {tv_sec =3D 0, tv_nsec =3D -1} wait =3D got_some_output =3D prev_wait_proc_nbytes_read =3D 0 retry_for_async =3D count =3D {bytes =3D } now =3D {tv_sec =3D , tv_nsec =3D } #47 0x0000556e0ec06a2f in kbd_buffer_get_event (kbp=3D, used_mouse_menu=3D, end_time= =3D) at ../../emacs/src/keyboard.c:4115 do_display =3D obj =3D str =3D had_pending_selection_requests =3D false had_pending_conversion_events =3D false obj =3D str =3D had_pending_selection_requests =3D had_pending_conversion_events =3D now =3D {tv_sec =3D , tv_nsec =3D } duration =3D {tv_sec =3D , tv_nsec =3D } do_display =3D tty =3D first =3D event =3D copy =3D {kind =3D , dpyinfo =3D , re= questor =3D , selection =3D , target =3D , property =3D , time =3D } --Type for more, q to quit, c to continue without paging-- f =3D frame =3D focus =3D pinch_dx =3D pinch_dy =3D pinch_angle =3D maybe_event =3D f =3D movement_frame =3D bar_window =3D part =3D x =3D y =3D t =3D frame =3D #48 read_event_from_main_queue (end_time=3Dend_time@entry=3D0x0, local_getcjmp=3Dlocal_getcjmp@entry= =3D0x7ffd3b15dd20, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7ffd3b15e00b= ) at ../../emacs/src/keyboard.c:2336 c =3D 0x0 save_jump =3D {{__jmpbuf =3D {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_s= aved =3D 0, __saved_mask =3D {__val =3D {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9393= 1182793087, 0, 0, 3, 93931182213056, 140725594737840}}}} kb =3D 0x556e2eb38850 count =3D {bytes =3D } #49 0x0000556e0ec0c5b6 in read_decoded_event_from_main_queue (end_time=3D, local_getcjmp=3D, prev_even= t=3D, used_mouse_menu=3D) at ../../emacs/src/= keyboard.c:2399 nextevt =3D --Type for more, q to quit, c to continue without paging-- frame =3D terminal =3D events =3D {0xd5b8, 0x0, 0x7f476553cee3, 0x1, 0x7ffd3b15dd00, 0x556= e0ed04dbf , 0x0, 0xd5b8, 0xecd6, 0x3b35, 0x7f478e= 045568, 0x7f478e04556d, 0x7ffd3b15de00, 0x556e0ec7a70c , 0xecd6, 0x7f478e045568} n =3D 0 events =3D { } n =3D nextevt =3D frame =3D terminal =3D meta_key =3D coding =3D i =3D c =3D modifier =3D src =3D { } dest =3D { } i =3D p =3D c =3D modifier =3D #50 read_char (commandflag=3D1, map=3Dmap@entry=3D0x7f4766b23feb, prev_event=3D0x0, u= sed_mouse_menu=3Dused_mouse_menu@entry=3D0x7ffd3b15e00b, end_time=3Dend_tim= e@entry=3D0x0) at ../../emacs/src/keyboard.c:3031 c =3D 0x0 local_getcjmp =3D {{__jmpbuf =3D {139948951031040, -121894828270294= 3986, 93931718281296, 0, 15403, 0, -1--Type for more, q to quit, c to= continue without paging-- 218948282577114866, -5029668301387126514}, __mask_was_saved =3D 0, __saved_= mask =3D {__val =3D {128, 0, 0, 50456, 93931184418448, 140725594742272, 939= 31182793475, 139948330862256, 15, 140725594742224, 93931182711373, 0, 46017= 145348552, 140725594742384, 93931182330548, 54712}}}} save_jump =3D {{__jmpbuf =3D {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_s= aved =3D 0, __saved_mask =3D {__val =3D {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9393= 1182793087, 0, 0, 3, 93931182213056, 140725594737840}}}} tem =3D save =3D previous_echo_area_message =3D 0x0 also_record =3D 0x0 reread =3D false recorded =3D false polling_stopped_here =3D true orig_kboard =3D 0x556e2eb38850 retry =3D jmpcount =3D {bytes =3D } c_volatile =3D 0x0 #51 0x0000556e0ec0f651 in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7ffd3b15e140, prompt=3Dprompt@entry=3D0x0, d= ont_downcase_last=3Ddont_downcase_last@entry=3Dfalse, can_return_switch_fra= me=3Dcan_return_switch_frame@entry=3Dtrue, fix_current_buffer=3Dfix_current= _buffer@entry=3Dtrue, prevent_redisplay=3Dprevent_redisplay@entry=3Dfalse, = disable_text_conversion_p=3Dfalse) at ../../emacs/src/keyboard.c:10790 interrupted_kboard =3D 0x556e2eb38850 interrupted_frame =3D key =3D used_mouse_menu =3D false echo_local_start =3D 0 last_real_key_start =3D --Type for more, q to quit, c to continue without paging-- keys_local_start =3D 0 new_binding =3D count =3D {bytes =3D } t =3D echo_start =3D 0 keys_start =3D 0 current_binding =3D 0x7f4766b23feb first_unbound =3D 31 mock_input =3D used_mouse_menu_history =3D {false } fkey =3D {parent =3D 0x7f4867545ab3, map =3D , start= =3D 0, end =3D 0} keytran =3D {parent =3D 0x7f4873e5c0d3, map =3D , st= art =3D 0, end =3D 0} indec =3D {parent =3D 0x7f4867545a9b, map =3D , star= t =3D 0, end =3D 0} shift_translated =3D delayed_switch_frame =3D original_uppercase =3D original_uppercase_position =3D disabled_conversion =3D starting_buffer =3D fake_prefixed_keys =3D 0x0 first_event =3D 0x0 second_event =3D #52 0x0000556e0ec114d8 in command_loop_1 () at ../../emacs/src/keyboard.c:1= 435 cmd =3D keybuf =3D {0xb2, 0x1d6, 0x1de, 0x0, 0x139e8, 0x556e0ee16e90, 0x7ff= d3b15e1e0, 0x556e0ec8a303 , 0x7f476b4ebe33, 0x7ffd3b15e200, = 0xc, 0x139e8, 0x38, 0x7f47bc51a55d, 0x29da64f38c80, 0x7f476b4ebe33, 0x60, 0= x7ffd3b15e200, 0x7ffd3b15e3b8, 0xffffffffffffffff, 0x7ffd3b15e260, 0x556e0e= c046bd , 0x--Type for more, q to quit, c to continue w= ithout paging-- 0, 0x0, 0xcb00, 0x556e0ee16e90, 0x7ffd3b15e280, 0x556e0ec8a303 , 0x0, 0xcbe0} i =3D last_pt =3D prev_modiff =3D 10245 prev_buffer =3D 0x7f478e045568 #53 0x0000556e0ec88f26 in internal_condition_case (bfun=3Dbfun@entry=3D0x556e0ec11320 , handlers=3Dhandle= rs@entry=3D0xa8, hfun=3Dhfun@entry=3D0x556e0ec04560 ) at ../../e= macs/src/eval.c:1626 val =3D c =3D 0x7f486598df68 #54 0x0000556e0ebfc43e in command_loop_2 (handlers=3Dhandlers@entry=3D0xa8)= at ../../emacs/src/keyboard.c:1174 val =3D #55 0x0000556e0ec88e52 in internal_catch (tag=3Dtag@entry=3D0x14dd0, func=3Dfunc@entry=3D0x556e0ebfc410 , arg=3Darg@entry=3D0xa8) at ../../emacs/src/eval.c:1305 val =3D c =3D #56 0x0000556e0ebfc3d3 in command_loop () at ../../emacs/src/keyboard.c:1152 #57 0x0000556e0ec040d6 in recursive_edit_1 () at ../../emacs/src/keyboard.c= :760 count =3D {bytes =3D } val =3D #58 0x0000556e0ec04488 in Frecursive_edit () at ../../emacs/src/keyboard.c:= 843 count =3D {bytes =3D } buffer =3D #59 0x0000556e0eae3296 in main (argc=3D, argv=3D0x7ffd3b15e5= d8) at ../../emacs/src/emacs.c:2580 stack_bottom_variable =3D 0x7f4877671ac0 old_argc =3D --Type for more, q to quit, c to continue without paging-- no_loadup =3D false junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0x0 original_pwd =3D dump_mode =3D skip_args =3D 1 temacs =3D 0x0 attempt_load_pdump =3D only_version =3D false rlim =3D {rlim_cur =3D 10022912, rlim_max =3D 18446744073709551615} lc_all =3D sockfd =3D -1 module_assertions =3D >> #7 0x0000556e0edd0c10 in shieldFlushEntries () > > shieldFlushEntries contains several asserts. Can you disassemble the > function shieldFlushEntries to see which one we hit? > (gdb: "disass/s shieldFlushEntries"). > (gdb) disass/s shieldFlushEntries Dump of assembler code for function shieldFlushEntries: 0x0000556e0edd0b80 <+0>: push %r15 0x0000556e0edd0b82 <+2>: push %r14 0x0000556e0edd0b84 <+4>: push %r13 0x0000556e0edd0b86 <+6>: push %r12 0x0000556e0edd0b88 <+8>: push %rbp 0x0000556e0edd0b89 <+9>: push %rbx 0x0000556e0edd0b8a <+10>: mov %rdi,%rbx 0x0000556e0edd0b8d <+13>: sub $0x8,%rsp 0x0000556e0edd0b91 <+17>: cmpq $0x0,0x18(%rbx) 0x0000556e0edd0b96 <+22>: mov 0x10(%rdi),%rdi 0x0000556e0edd0b9a <+26>: jne 0x556e0edd0bb8 0x0000556e0edd0b9c <+28>: test %rdi,%rdi 0x0000556e0edd0b9f <+31>: jne 0x556e0edd0cd0 0x0000556e0edd0ba5 <+37>: add $0x8,%rsp 0x0000556e0edd0ba9 <+41>: pop %rbx 0x0000556e0edd0baa <+42>: pop %rbp 0x0000556e0edd0bab <+43>: pop %r12 0x0000556e0edd0bad <+45>: pop %r13 0x0000556e0edd0baf <+47>: pop %r14 0x0000556e0edd0bb1 <+49>: pop %r15 0x0000556e0edd0bb3 <+51>: ret 0x0000556e0edd0bb4 <+52>: nopl 0x0(%rax) 0x0000556e0edd0bb8 <+56>: mov 0x28(%rbx),%rsi 0x0000556e0edd0bbc <+60>: lea 0x48(%rbx),%r8 0x0000556e0edd0bc0 <+64>: mov $0xb60405ed,%ecx 0x0000556e0edd0bc5 <+69>: lea -0x658fc(%rip),%rdx # 0x556e0= ed6b2d0 --Type for more, q to quit, c to con= tinue without paging-- 0x0000556e0edd0bcc <+76>: call 0x556e0ed74d40 0x0000556e0edd0bd1 <+81>: cmpq $0x0,0x28(%rbx) 0x0000556e0edd0bd6 <+86>: je 0x556e0edd0cb8 0x0000556e0edd0bdc <+92>: xor %ebp,%ebp 0x0000556e0edd0bde <+94>: xor %r12d,%r12d 0x0000556e0edd0be1 <+97>: xor %r14d,%r14d 0x0000556e0edd0be4 <+100>: xor %r13d,%r13d 0x0000556e0edd0be7 <+103>: jmp 0x556e0edd0c34 0x0000556e0edd0be9 <+105>: nopl 0x0(%rax) 0x0000556e0edd0bf0 <+112>: test %r13,%r13 0x0000556e0edd0bf3 <+115>: je 0x556e0edd0c91 0x0000556e0edd0bf9 <+121>: cmp %r14,%r13 0x0000556e0edd0bfc <+124>: jae 0x556e0edd0d00 0x0000556e0edd0c02 <+130>: mov %r12d,%edx 0x0000556e0edd0c05 <+133>: mov %r14,%rsi 0x0000556e0edd0c08 <+136>: mov %r13,%rdi 0x0000556e0edd0c0b <+139>: call 0x556e0edcf8b0 0x0000556e0edd0c10 <+144>: movzwl 0x30(%r15),%r12d 0x0000556e0edd0c15 <+149>: shr $0x7,%r12w 0x0000556e0edd0c1a <+154>: and $0x3,%r12d 0x0000556e0edd0c1e <+158>: mov 0x10(%r15),%rax 0x0000556e0edd0c22 <+162>: mov 0x10(%rax),%r13 0x0000556e0edd0c26 <+166>: mov 0x28(%r15),%r14 0x0000556e0edd0c2a <+170>: add $0x1,%rbp 0x0000556e0edd0c2e <+174>: cmp 0x28(%rbx),%rbp 0x0000556e0edd0c32 <+178>: jae 0x556e0edd0ca0 --Type for more, q to quit, c to continue without paging-- 0x0000556e0edd0c34 <+180>: mov %rbp,%rsi 0x0000556e0edd0c37 <+183>: mov %rbx,%rdi 0x0000556e0edd0c3a <+186>: call 0x556e0ed806d0 0x0000556e0edd0c3f <+191>: movzwl 0x30(%rax),%edx 0x0000556e0edd0c43 <+195>: mov %rax,%r15 0x0000556e0edd0c46 <+198>: movzbl 0x30(%rax),%eax 0x0000556e0edd0c4a <+202>: shr $0x7,%dx 0x0000556e0edd0c4e <+206>: shr $0x5,%al 0x0000556e0edd0c51 <+209>: and $0x3,%edx 0x0000556e0edd0c54 <+212>: and $0x3,%eax 0x0000556e0edd0c57 <+215>: cmp %al,%dl 0x0000556e0edd0c59 <+217>: je 0x556e0edd0c2a 0x0000556e0edd0c5b <+219>: movzbl %dl,%edx 0x0000556e0edd0c5e <+222>: mov %r15,%rsi 0x0000556e0edd0c61 <+225>: mov %rbx,%rdi 0x0000556e0edd0c64 <+228>: call 0x556e0ed6ed50 0x0000556e0edd0c69 <+233>: movzwl 0x30(%r15),%eax 0x0000556e0edd0c6e <+238>: shr $0x7,%ax 0x0000556e0edd0c72 <+242>: and $0x3,%eax 0x0000556e0edd0c75 <+245>: cmp %r12d,%eax 0x0000556e0edd0c78 <+248>: jne 0x556e0edd0bf0 0x0000556e0edd0c7e <+254>: mov 0x10(%r15),%rdx 0x0000556e0edd0c82 <+258>: cmp 0x10(%rdx),%r14 0x0000556e0edd0c86 <+262>: je 0x556e0edd0c26 0x0000556e0edd0c88 <+264>: test %r13,%r13 0x0000556e0edd0c8b <+267>: jne 0x556e0edd0bf9 0x0000556e0edd0c91 <+273>: mov %eax,%r12d --Type for more, q to quit, c to continue without paging-- 0x0000556e0edd0c94 <+276>: jmp 0x556e0edd0c1e 0x0000556e0edd0c96 <+278>: cs nopw 0x0(%rax,%rax,1) 0x0000556e0edd0ca0 <+288>: test %r13,%r13 0x0000556e0edd0ca3 <+291>: je 0x556e0edd0cb8 0x0000556e0edd0ca5 <+293>: cmp %r14,%r13 0x0000556e0edd0ca8 <+296>: jae 0x556e0edd0d1e 0x0000556e0edd0caa <+298>: mov %r12d,%edx 0x0000556e0edd0cad <+301>: mov %r14,%rsi 0x0000556e0edd0cb0 <+304>: mov %r13,%rdi 0x0000556e0edd0cb3 <+307>: call 0x556e0edcf8b0 0x0000556e0edd0cb8 <+312>: add $0x8,%rsp 0x0000556e0edd0cbc <+316>: mov %rbx,%rdi 0x0000556e0edd0cbf <+319>: pop %rbx 0x0000556e0edd0cc0 <+320>: pop %rbp 0x0000556e0edd0cc1 <+321>: pop %r12 0x0000556e0edd0cc3 <+323>: pop %r13 0x0000556e0edd0cc5 <+325>: pop %r14 0x0000556e0edd0cc7 <+327>: pop %r15 0x0000556e0edd0cc9 <+329>: jmp 0x556e0ed6b260 0x0000556e0edd0cce <+334>: xchg %ax,%ax 0x0000556e0edd0cd0 <+336>: add $0x8,%rsp 0x0000556e0edd0cd4 <+340>: lea 0x3c4e3(%rip),%rdx # 0x556e0e= e0d1be 0x0000556e0edd0cdb <+347>: mov $0x190,%esi 0x0000556e0edd0ce0 <+352>: pop %rbx 0x0000556e0edd0ce1 <+353>: lea 0x3a269(%rip),%rdi # 0x556e0e= e0af51 0x0000556e0edd0ce8 <+360>: pop %rbp 0x0000556e0edd0ce9 <+361>: pop %r12 --Type for more, q to quit, c to continue without paging-- 0x0000556e0edd0ceb <+363>: pop %r13 0x0000556e0edd0ced <+365>: pop %r14 0x0000556e0edd0cef <+367>: pop %r15 0x0000556e0edd0cf1 <+369>: jmp *0xbbb79(%rip) # 0x556e0ee8c8= 70 0x0000556e0edd0cf7 <+375>: nopw 0x0(%rax,%rax,1) 0x0000556e0edd0d00 <+384>: lea 0x3a97c(%rip),%rdx # 0x556e0e= e0b683 0x0000556e0edd0d07 <+391>: mov $0x1a0,%esi 0x0000556e0edd0d0c <+396>: lea 0x3a23e(%rip),%rdi # 0x556e0e= e0af51 0x0000556e0edd0d13 <+403>: call *0xbbb57(%rip) # 0x556e0ee8c8= 70 0x0000556e0edd0d19 <+409>: jmp 0x556e0edd0c02 0x0000556e0edd0d1e <+414>: lea 0x3a95e(%rip),%rdx # 0x556e0e= e0b683 0x0000556e0edd0d25 <+421>: mov $0x1aa,%esi 0x0000556e0edd0d2a <+426>: lea 0x3a220(%rip),%rdi # 0x556e0e= e0af51 0x0000556e0edd0d31 <+433>: call *0xbbb39(%rip) # 0x556e0ee8c8= 70 0x0000556e0edd0d37 <+439>: jmp 0x556e0edd0caa End of assembler dump. >> #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output >> (p=3D, chars=3D0x556e40d23290 ",{\"detail\":\"void >> (lxw_workbook *, >> decltype(lxw_workbook::options))\",\"kind\":6,\"name\":\"w\",\"range\":{= \"end\":{\"character\":57,\"line\":12784},\"start\":{\"character\":0,\"line= \":12784}},\"selectionRange\":{\"end\":{\"cha"..., >> nbytes=3D335897, coding=3D0x556e2eba74b0) > > 335 KB? That's a lot, That's lsp/libclang for you. I only use it occasionally and that was a large C++ file. However, I use lsp/dart all the time, with smaller files but the server is quite verbose, and no crashes so far. > so it's likely that the problem was caused in the > json code... I'll have a look, particularly at xcdr_addr, which is > rarely used in other code. >> In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo >> version 1.18.2) of 2025-02-13 built on zen >> Repository revision: 4b28c41c4f2b43add865f9a8727879cb53dad107 > > Hmm. That's a bit older, but I don't think this looks like any of the > bugs that have been fixed since. > > Thanks for the report, I'll try stress-testing the JSON code next. Thank you Pip. _________________________________________________________________ ________________________________________________________ Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 10:36:37 2025 Received: (at submit) by debbugs.gnu.org; 3 Mar 2025 15:36:37 +0000 Received: from localhost ([127.0.0.1]:50163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp7qO-0004sz-NN for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:36:37 -0500 Received: from lists.gnu.org ([2001:470:142::17]:46416) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp7qL-0004sM-SR for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:36:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp7qC-00037c-8J for bug-gnu-emacs@gnu.org; Mon, 03 Mar 2025 10:36:25 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp7q9-0006Si-Gj for bug-gnu-emacs@gnu.org; Mon, 03 Mar 2025 10:36:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741016174; x=1741275374; bh=Zknns6H6WhBXV4YJOLvjkXQHUbEIfXBBpmwUmpuUTqQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=wANCgyCMkLrMg34jtl+TOUs3AUvodGjUWarHgDBtM6p6TQpdEmTfLoyZIaLjXueZB uZPY5E9j4u8Nkv93ISYty5Fdts3ewPU9Fnrf5R9YUV63ZsZ0IxyDPIoBfz9MhtW+NY wWZC5JUJPkMPFrDEULy1WVZA8mAS3ZbDPj0N68zJcReV8sbDHTLz9gFz1RhLMTljju wbI43FiW3xTcDzxQHejeph1cSezOzDuiWlJjwemmkttYxEniwWNFafwOAQBhkF2MRq Rb3ajxNxB4wHtICUvvOqXFEvilyU9zC+leKs9FNWd8GqcF9ENxs6VNz/occef6Wzvx OakJFEBZy3cAw== Date: Mon, 03 Mar 2025 15:36:09 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash Message-ID: <87wmd6w2id.fsf@protonmail.com> In-Reply-To: <878qpm9mig.fsf@telefonica.net> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8df885f8f30bd8a586af115796f460b850bdec6a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=79.135.106.31; envelope-from=pipcet@protonmail.com; helo=mail-10631.protonmail.ch X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) =C3=93scar Fuentes writes: > Pip Cet writes: > >> =C3=93scar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife = of text editors" writes: >> >>> Emacs just crashed on a session started more than a week ago, IIRC. >>> >>> The following backtrace is from the core dump. Sorry for not being more >>> helpful. >> >> Can you try generating a full backtrace ("bt full" should work on the >> core dump, too)? Thanks! Two new leads :-) > #0 __pthread_kill_implementation (threadid=3D, signo=3Dsi= gno@entry=3D6, no_tid=3Dno_tid@entry=3D0) > at ./nptl/pthread_kill.c:44 > tid =3D > ret =3D 0 > pd =3D > old_mask =3D {__val =3D {0}} > ret =3D > #1 0x00007f487751de2f in __pthread_kill_internal (threadid=3D, signo=3D6) > at ./nptl/pthread_kill.c:78 > #2 0x00007f48774c9d02 in __GI_raise (sig=3Dsig@entry=3D6) at ../sysdeps/= posix/raise.c:26 > ret =3D > #3 0x0000556e0ead9d68 in terminate_due_to_signal > (sig=3Dsig@entry=3D6, backtrace_limit=3Dbacktrace_limit@entry=3D21474= 83647) at ../../emacs/src/emacs.c:463 > #4 0x0000556e0ed16d73 in set_state (state=3DIGC_STATE_DEAD) at ../../ema= cs/src/igc.c:1023 > old_state =3D > old_state =3D > #5 set_state (state=3DIGC_STATE_DEAD) at ../../emacs/src/igc.c:1002 > old_state =3D > #6 igc_assert_fail (file=3D, line=3D, msg= =3D) > at ../../emacs/src/igc.c:306 It's a pity we don't have this message... > #7 0x0000556e0edd0c10 in shieldFlushEntries () So it seems that this function called ProtSet (see the code below), and ProtSet tail-called mps_lib_assert_fail. In my build, it only does that when mprotect fails, which is something that happened in another bug report. I assume this is a Linux kernel? My assumption is that errno is ENOMEM (you should be able to figure this out from the core dump, but I don't know how glibc hides errno these days): =09ENOMEM =09=09Changing the protection of a memory region would result in =09=09the total number of mappings with distinct attributes (e.g., =09=09read versus read/write protection) exceeding the allowed =09=09maximum. (For example, making the protection of a range =09=09PROT_READ in the middle of a region currently protected as =09=09PROT_READ|PROT_WRITE would result in three mappings: two =09=09read/write mappings at each end and a read-only mapping in =09=09the middle.) That sounds like something that might happen. I assume there's a sysctl or ulimit controlling this limit. Can you do an objdump -h on the core file, reporting only the count of "load" sections? (Over here, I see about 3000 sections, which is a lot). What is the output of cat /proc/sys/vm/max_map_count ? It is 65530 here, and that's not a lot more than 3000. There are recommendations on the internet to increase this limit, so I'll try reducing it and seeing whether it causes my Emacs to crash... If that is indeed the problem, we should probably increase the arena grain size, which means more than one of the tiny 4 KB pages x86 has will be mprotected at a time, reducing the number of maps... > #38 Fjson_parse_buffer (nargs=3D, args=3D) = at ../../emacs/src/json.c:1812 > count =3D {bytes =3D } > conf =3D {object_type =3D , array_type =3D , null_object =3D , false_object =3D = } > p =3D {input_current =3D 0x556e3342596e "}],\"detail\":\"struct\"= ,\"kind\":23,\"name\":\"ra_struct_0xAB71CCE7u\",\"range\":{\"end\":{\= "character\":62,\"line\":9091},\"start\":{\"character\":0,\"line\":9091}},\= "selectionRange\":{\"end\":{\"character\":10,\"line\":9091"..., input_begin= =3D 0x556e32ee1f60 "{\"id\":17456,\"jsonrpc\":\"2.0\",\"result\":[{\"child= ren\":[{\"detail\":\"lp0::PluginInfoAdder\",\"kind\":13,\"name\":\"ppa8\",\= "range\":{\"end\":{\"character\":33,\"line\":7},\"start\":{\"character\":0,= \"line\":7}},\"selectionRange\":"..., input_end =3D 0x556e33733f5e "", seco= ndary_input_begin =3D 0x0, secondary_input_end =3D 0x0, current_line =3D 1,= current_column =3D 5519886, point_of_current_line =3D 0, available_depth = =3D 9993, conf =3D {object_type =3D json_object_hashtable, array_type =3D j= son_array_array, null_object =3D 0x0, false_object =3D 0x0}, additional_byt= es_count =3D 0, internal_object_workspace =3D {0x7f4767c48874, 0x110c2, 0x7= f4767c4889c, 0x7f4767c488c4, 0x7f4767c4972d, 0x7f4767c4c63d, 0x7f4767c4cd4d= , 0x7f4767c4f9c5, 0x7f4767c53005, 0x7f4767c53ef5, 0x7f4767c54df5, 0x7f4767c= 55ce5, 0x7f4767c58bf5, 0x7f4767c59ae5, 0x7f4767c5c76d, 0x7f4767c5dd9d, 0x7f= 4767c60c8d, 0x7f4767c61b7d, 0x7f4767c62a6d, 0x7f4767c6395d, 0x7f4767c6689d,= 0x7f4767c6778d, 0x7f4767c6868d, 0x7f4767c6957d, 0x7f4767c6c48d, 0x7f4767c6= d37d, 0x7f4767c6e26d, 0x7f4767c6f15d, 0x7f4767c7009d, 0x7f4767c70f8d, 0x7f4= 767c71e7d, 0x7f4767c74d7d, 0x7f4767c75c6d, 0x7f4767c76b7d, 0x7f4767c77a6d, = 0x7f4767c7a9ad, 0x7f4767c7b89d, 0x7f4767c7c78d, 0x7f4767c7d67d, 0x7f4767c80= 575, 0x7f4767c81465, 0x7f4767c8237d, 0x7f4767c8326d, 0x7f4767c8615d, 0x7f47= 67c8704d, 0x7f4767c87f3d, 0x7f4767c88e5d, 0x7f4767c89d4d, 0x7f4767c8cc8d, 0= x7f4767c8cd64, 0x7f4767c8d4dd, 0x7f4767c--Type for more, q to quit, c= to continue without paging-- > 8d4f4, 0x7f4767c8d51c, 0x7f4767c8d544, 0x56, 0x7f4767c8d56c, 0x7f4767c8d5= 94, 0x7f4767c8d5bc, 0x7f4767c8d805, 0x7f4767c8d8c4, 0x7f4767c8d93d, 0x7f476= 7c8d9fc, 0x2, 0x21e}, object_workspace =3D 0x556e374c43e0, object_workspace= _size =3D 4096, object_workspace_current =3D 4023, internal_byte_workspace = =3D "9091acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options = *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177\000\000\000\00= 0\000\000\000\000\000\000\020\370\302\016nU\000\000\b\000\000\000\000\000\0= 00\000\020\321\025;\375\177\000\000\t\000\000\000\000\000\000\000\310\321\0= 25;\375\177\000\000\000\000\000\000\000\000\000\000\020\370\302\016nU\000\0= 00\b\000\000\000\000\000\000\000p\321\025;\375\177\000\000"..., byte_worksp= ace =3D 0x7ffd3b15d050 "9091acterRange(lxw_chart_options::x_scale) *, const= lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375= \177", byte_workspace_end =3D 0x7ffd3b15d250 "P\320\025;\375\177", byte_wor= kspace_current =3D 0x7ffd3b15d054 "acterRange(lxw_chart_options::x_scale) *= , const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\0= 25;\375\177"} I see that the object_workspace is large, which means several rounds of allocation most likely happened. If this happens a lot, I'm not sure whether it creates more mappings that count against max_map_count. >>> #7 0x0000556e0edd0c10 in shieldFlushEntries () >> >> shieldFlushEntries contains several asserts. Can you disassemble the >> function shieldFlushEntries to see which one we hit? >> (gdb: "disass/s shieldFlushEntries"). >> > > (gdb) disass/s shieldFlushEntries > Dump of assembler code for function shieldFlushEntries: > 0x0000556e0edd0be1 <+97>: xor %r14d,%r14d > 0x0000556e0edd0be4 <+100>: xor %r13d,%r13d > 0x0000556e0edd0be7 <+103>: jmp 0x556e0edd0c34 > 0x0000556e0edd0be9 <+105>: nopl 0x0(%rax) > 0x0000556e0edd0bf0 <+112>: test %r13,%r13 > 0x0000556e0edd0bf3 <+115>: je 0x556e0edd0c91 > 0x0000556e0edd0bf9 <+121>: cmp %r14,%r13 > 0x0000556e0edd0bfc <+124>: jae 0x556e0edd0d00 > 0x0000556e0edd0c02 <+130>: mov %r12d,%edx > 0x0000556e0edd0c05 <+133>: mov %r14,%rsi > 0x0000556e0edd0c08 <+136>: mov %r13,%rdi > 0x0000556e0edd0c0b <+139>: call 0x556e0edcf8b0 > =3D> 0x0000556e0edd0c10 <+144>: movzwl 0x30(%r15),%r12d Thanks! This means that it was actually ProtSet which aborted, and since it doesn't show up in the backtrace it must have tail-called the assertion function. Can you disassemble ProtSet just to make sure that we're looking at an mprotect failure here? Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 10:50:07 2025 Received: (at 76705) by debbugs.gnu.org; 3 Mar 2025 15:50:07 +0000 Received: from localhost ([127.0.0.1]:50283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp83S-0005vw-Eu for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:50:07 -0500 Received: from mail.eclipso.de ([217.69.254.104]:52972) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp83O-0005v2-Q9 for 76705@debbugs.gnu.org; Mon, 03 Mar 2025 10:50:04 -0500 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1741016995; bh=xbQyFp0uDTcZUYEWXUsvUDu7Qh5uTQlFMvA0KA97ozI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MZ6R42cs2EPQRlt803HGaLdPq++iuN9GmA/Yv8ABmZ5rGpzaU9dIkz5ktbtA+Tr3Z jAHeVWr1eWKgaPzEC+AnWcua4YCttM8bzQ8iumTGnUZHTxiPZnWtTBVFLhk2sN3+OV jZkjVcCZnhkPi4BHq23DOP/QeQ9rHFxpoJKEoB+IwkXJjrofAGOEF9CJgLJZKpIgNL bY17GYMG+girKoBZE4w2hxDfqw63s1/j2pDOxclGFAylFMWYN6Qly2W/IISADxkE4N 3ubXo3tVR2t9RmISWY/R2rOrhNQ+WSf/nz/gttMMNes1/mmyx66RRkzQHJgNPmY1Rr WOIPskY+TihqQ== To: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash In-Reply-To: <87wmd6w2id.fsf@protonmail.com> (Pip Cet's message of "Mon, 03 Mar 2025 15:36:09 +0000") References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> Date: Mon, 03 Mar 2025 16:49:54 +0100 Message-ID: <871pve9krh.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76705 Cc: 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Pip Cet writes: > I assume this is a Linux kernel? Correct. $ uname -a Linux zen 6.12.11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.11-1 (2025-01-25) x86_64 GNU/Linux > Can you do an objdump -h on the core file, reporting only the count of > "load" sections? (Over here, I see about 3000 sections, which is a > lot). Tail of objdump -h : 9260 load8395 15760000 0000556e2e8c0000 0000000000000000 9d20f000 2**12 CONTENTS, ALLOC, LOAD $ objdump -h dump | grep " load" | wc 9237 64659 747221 > What is the output of > > cat /proc/sys/vm/max_map_count > > ? It is 65530 here, Same here. > Thanks! This means that it was actually ProtSet which aborted, and since > it doesn't show up in the backtrace it must have tail-called the > assertion function. Can you disassemble ProtSet just to make sure that > we're looking at an mprotect failure here? (gdb) disass/s ProtSet Dump of assembler code for function ProtSet: 0x0000556e0edcf8b0 <+0>: push %r12 0x0000556e0edcf8b2 <+2>: mov %edx,%r12d 0x0000556e0edcf8b5 <+5>: push %rbp 0x0000556e0edcf8b6 <+6>: mov %rdi,%rbp 0x0000556e0edcf8b9 <+9>: push %rbx 0x0000556e0edcf8ba <+10>: mov %rsi,%rbx 0x0000556e0edcf8bd <+13>: cmp %rsi,%rdi 0x0000556e0edcf8c0 <+16>: jae 0x556e0edcf958 0x0000556e0edcf8c6 <+22>: test %rbp,%rbp 0x0000556e0edcf8c9 <+25>: je 0x556e0edcf980 0x0000556e0edcf8cf <+31>: sub %rbp,%rbx 0x0000556e0edcf8d2 <+34>: cmp $0x7fffffff,%rbx 0x0000556e0edcf8d9 <+41>: ja 0x556e0edcf9b0 0x0000556e0edcf8df <+47>: mov $0x5,%edx 0x0000556e0edcf8e4 <+52>: cmp $0x2,%r12d 0x0000556e0edcf8e8 <+56>: je 0x556e0edcf8f6 0x0000556e0edcf8ea <+58>: ja 0x556e0edcf930 0x0000556e0edcf8ec <+60>: mov $0x7,%edx 0x0000556e0edcf8f1 <+65>: test %r12d,%r12d 0x0000556e0edcf8f4 <+68>: jne 0x556e0edcf94f 0x0000556e0edcf8f6 <+70>: mov %rbx,%rsi 0x0000556e0edcf8f9 <+73>: mov %rbp,%rdi 0x0000556e0edcf8fc <+76>: call 0x556e0ead23b0 0x0000556e0edcf901 <+81>: test %eax,%eax 0x0000556e0edcf903 <+83>: je 0x556e0edcf928 0x0000556e0edcf905 <+85>: pop %rbx --Type for more, q to quit, c to continue without paging-- 0x0000556e0edcf906 <+86>: lea 0x3b536(%rip),%rdx # 0x556e0ee0ae43 0x0000556e0edcf90d <+93>: pop %rbp 0x0000556e0edcf90e <+94>: mov $0x75,%esi 0x0000556e0edcf913 <+99>: lea 0x4011b(%rip),%rdi # 0x556e0ee0fa35 0x0000556e0edcf91a <+106>: pop %r12 0x0000556e0edcf91c <+108>: jmp *0xbcf4e(%rip) # 0x556e0ee8c870 0x0000556e0edcf922 <+114>: nopw 0x0(%rax,%rax,1) 0x0000556e0edcf928 <+120>: pop %rbx 0x0000556e0edcf929 <+121>: pop %rbp 0x0000556e0edcf92a <+122>: pop %r12 0x0000556e0edcf92c <+124>: ret 0x0000556e0edcf92d <+125>: nopl (%rax) 0x0000556e0edcf930 <+128>: cmp $0x3,%r12d 0x0000556e0edcf934 <+132>: je 0x556e0edcf94f 0x0000556e0edcf936 <+134>: lea 0x3b506(%rip),%rdx # 0x556e0ee0ae43 0x0000556e0edcf93d <+141>: mov $0x64,%esi 0x0000556e0edcf942 <+146>: lea 0x400ec(%rip),%rdi # 0x556e0ee0fa35 0x0000556e0edcf949 <+153>: call *0xbcf21(%rip) # 0x556e0ee8c870 0x0000556e0edcf94f <+159>: xor %edx,%edx 0x0000556e0edcf951 <+161>: jmp 0x556e0edcf8f6 0x0000556e0edcf953 <+163>: nopl 0x0(%rax,%rax,1) 0x0000556e0edcf958 <+168>: lea 0x3bd24(%rip),%rdx # 0x556e0ee0b683 0x0000556e0edcf95f <+175>: mov $0x49,%esi 0x0000556e0edcf964 <+180>: lea 0x400ca(%rip),%rdi # 0x556e0ee0fa35 0x0000556e0edcf96b <+187>: call *0xbceff(%rip) # 0x556e0ee8c870 0x0000556e0edcf971 <+193>: test %rbp,%rbp 0x0000556e0edcf974 <+196>: jne 0x556e0edcf8cf --Type for more, q to quit, c to continue without paging-- 0x0000556e0edcf97a <+202>: nopw 0x0(%rax,%rax,1) 0x0000556e0edcf980 <+208>: sub %rbp,%rbx 0x0000556e0edcf983 <+211>: lea 0x3bbea(%rip),%rdx # 0x556e0ee0b574 0x0000556e0edcf98a <+218>: mov $0x4a,%esi 0x0000556e0edcf98f <+223>: lea 0x4009f(%rip),%rdi # 0x556e0ee0fa35 0x0000556e0edcf996 <+230>: call *0xbced4(%rip) # 0x556e0ee8c870 0x0000556e0edcf99c <+236>: cmp $0x7fffffff,%rbx 0x0000556e0edcf9a3 <+243>: jbe 0x556e0edcf8df 0x0000556e0edcf9a9 <+249>: nopl 0x0(%rax) 0x0000556e0edcf9b0 <+256>: lea 0x25751(%rip),%rdx # 0x556e0edf5108 0x0000556e0edcf9b7 <+263>: mov $0x4b,%esi 0x0000556e0edcf9bc <+268>: lea 0x40072(%rip),%rdi # 0x556e0ee0fa35 0x0000556e0edcf9c3 <+275>: call *0xbcea7(%rip) # 0x556e0ee8c870 0x0000556e0edcf9c9 <+281>: jmp 0x556e0edcf8df End of assembler dump. HTH _________________________________________________________________ ________________________________________________________ Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 11:11:20 2025 Received: (at 76705) by debbugs.gnu.org; 3 Mar 2025 16:11:20 +0000 Received: from localhost ([127.0.0.1]:50476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp8Nz-0007p2-MI for submit@debbugs.gnu.org; Mon, 03 Mar 2025 11:11:20 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:16395) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp8Nv-0007nv-11 for 76705@debbugs.gnu.org; Mon, 03 Mar 2025 11:11:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741018267; x=1741277467; bh=Qr6i2dHUe6tz/pJOxXXp1EJjt9Bp5nAHrS2MHy7nnD0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=BJWVzfokPwH+7msnteXUhRuPokRL1u1cuhnpcfRbmgwOdkq3OZ7lRisM6gtoatcOI LVMOlJ0bLG3WFSVN6Xb4x/EfLhyfAG/6qZU5CSvzGjbsG30UAuU43plpnGP2hTSuKN s0tuVgNOPXH+cBeO9OIBJRjEjlpxVEH18FLQANuJZ2viibh61SoBhj6eHBPYenJ3ke kiS9ogYN/LM3awLiBWyofHw+I6aOM9IAWkSvYpY3H3uhgmuhizLBaMKG4d8TvRFzMA UKoAS6JbPD6nnJo+wyGAlqqWaraL5blwo05abW76iAlIAleLzCHXwZKl6aD4o4VFWE CCXBUFE6Zqrrg== Date: Mon, 03 Mar 2025 16:11:03 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash Message-ID: <87wmd69jt3.fsf@protonmail.com> In-Reply-To: <871pve9krh.fsf@telefonica.net> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e74df434c93fe14bd16f9d98fb909f2c18a5426a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 76705 Cc: 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > Pip Cet writes: > >> I assume this is a Linux kernel? > > Correct. > > $ uname -a > Linux zen 6.12.11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.11-1 (2025-01-= 25) x86_64 GNU/Linux > >> Can you do an objdump -h on the core file, reporting only the count of >> "load" sections? (Over here, I see about 3000 sections, which is a >> lot). > > Tail of objdump -h : > > 9260 load8395 15760000 0000556e2e8c0000 0000000000000000 9d20f000= 2**12 > CONTENTS, ALLOC, LOAD > > $ objdump -h dump | grep " load" | wc > 9237 64659 747221 Hmm. Is it possible that increases by a factor of 6 during a collection? How large is the core file? >> What is the output of >> >> cat /proc/sys/vm/max_map_count >> >> ? It is 65530 here, > > Same here. I set it to 4096, and that crashed my MPS Emacs when I started a collection (which is when the mprotect calls happen), so running against this limit during a collection is my current best theory. If this is indeed an issue, we might have to increase ARENA_GRAIN_SIZE, or submit a patch to MPS... However, I would still like to see errno =3D ENOMEM to be sure :-) >> Thanks! This means that it was actually ProtSet which aborted, and since >> it doesn't show up in the backtrace it must have tail-called the >> assertion function. Can you disassemble ProtSet just to make sure that >> we're looking at an mprotect failure here? > > (gdb) disass/s ProtSet > Dump of assembler code for function ProtSet: > 0x0000556e0edcf8b0 <+0>: push %r12 > 0x0000556e0edcf8b2 <+2>: mov %edx,%r12d > 0x0000556e0edcf8b5 <+5>: push %rbp > 0x0000556e0edcf8b6 <+6>: mov %rdi,%rbp Hmm. You've compiled MPS without -fno-omit-frame-pointer. I think (hope!) that's safe as only references created outside of MPS can pin objects... > 0x0000556e0edcf8b9 <+9>: push %rbx > 0x0000556e0edcf8ba <+10>: mov %rsi,%rbx > 0x0000556e0edcf8bd <+13>: cmp %rsi,%rdi > 0x0000556e0edcf8c0 <+16>: jae 0x556e0edcf958 > 0x0000556e0edcf8c6 <+22>: test %rbp,%rbp > 0x0000556e0edcf8c9 <+25>: je 0x556e0edcf980 > 0x0000556e0edcf8cf <+31>: sub %rbp,%rbx > 0x0000556e0edcf8d2 <+34>: cmp $0x7fffffff,%rbx > 0x0000556e0edcf8d9 <+41>: ja 0x556e0edcf9b0 > 0x0000556e0edcf8df <+47>: mov $0x5,%edx > 0x0000556e0edcf8e4 <+52>: cmp $0x2,%r12d > 0x0000556e0edcf8e8 <+56>: je 0x556e0edcf8f6 > 0x0000556e0edcf8ea <+58>: ja 0x556e0edcf930 > 0x0000556e0edcf8ec <+60>: mov $0x7,%edx > 0x0000556e0edcf8f1 <+65>: test %r12d,%r12d > 0x0000556e0edcf8f4 <+68>: jne 0x556e0edcf94f > 0x0000556e0edcf8f6 <+70>: mov %rbx,%rsi > 0x0000556e0edcf8f9 <+73>: mov %rbp,%rdi > 0x0000556e0edcf8fc <+76>: call 0x556e0ead23b0 > 0x0000556e0edcf901 <+81>: test %eax,%eax > 0x0000556e0edcf903 <+83>: je 0x556e0edcf928 This calls mprotect, and we only reach it when the return value is nonzero. > 0x0000556e0edcf905 <+85>: pop %rbx > --Type for more, q to quit, c to continue without paging-- > 0x0000556e0edcf906 <+86>: lea 0x3b536(%rip),%rdx # 0x556e= 0ee0ae43 > 0x0000556e0edcf90d <+93>: pop %rbp > 0x0000556e0edcf90e <+94>: mov $0x75,%esi > 0x0000556e0edcf913 <+99>: lea 0x4011b(%rip),%rdi # 0x556e= 0ee0fa35 > 0x0000556e0edcf91a <+106>: pop %r12 > 0x0000556e0edcf91c <+108>: jmp *0xbcf4e(%rip) # 0x556e0ee8= c870 And this tail-calls mps_lib_assert_handler, and it's the only place that does so. So it's definitely a failed mprotect. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 11:21:27 2025 Received: (at 76705) by debbugs.gnu.org; 3 Mar 2025 16:21:27 +0000 Received: from localhost ([127.0.0.1]:50559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp8Xn-0000H9-D4 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 11:21:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49400) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp8Xj-0000GS-My for 76705@debbugs.gnu.org; Mon, 03 Mar 2025 11:21:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tp8Xd-0005wJ-II; Mon, 03 Mar 2025 11:21:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bdedCudD9znSmhdWjqG9CN+navk4GcZd9wLtdePI+Hg=; b=rbNHKYQ8XSWF ReieHEDFwYkXf2nw6NlLtUbe5Rdc7lU103LKv8GP0cWQ5YS7hYa4R0BxOv5bY67ydxXGJ2EBgOfUY C1hv+tbwCGyFanThOUXAN/jL7RLIlE2F91mz/xDQRrP8K/aCit5XkEtVfsdiOB4nsG7gfZ848BzHL cz/nJHk5MKyZNfYz0ebh5xPktbHPAX3j9+gvvFkDNSgHiab997SXHXEODdeH39pnPVAPBU+Mrx5Ya RpVMkTibYT9SfkNR4q/6J3UszITOrW4HL2K7YUu4hYM42yeysUUIlNglDuGJXz/6bjmCxgmJZ8RrE 40GV1Au3K4V9ajZdW/BigA==; Date: Mon, 03 Mar 2025 18:21:14 +0200 Message-Id: <868qpmkrut.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87wmd6w2id.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#76705: 31.0.50; igc: crash References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76705 Cc: oscarfv@eclipso.eu, 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 76705@debbugs.gnu.org > Date: Mon, 03 Mar 2025 15:36:09 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > #7 0x0000556e0edd0c10 in shieldFlushEntries () > > So it seems that this function called ProtSet (see the code below), and > ProtSet tail-called mps_lib_assert_fail. In my build, it only does that > when mprotect fails, which is something that happened in another bug > report. > > I assume this is a Linux kernel? My assumption is that errno is ENOMEM > (you should be able to figure this out from the core dump, but I don't > know how glibc hides errno these days): In GDB, type "ptype errno" and/or "whatis errno", and go from there. (I believe it expands to a function or a TLS reference?) From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 11:50:28 2025 Received: (at 76705) by debbugs.gnu.org; 3 Mar 2025 16:50:28 +0000 Received: from localhost ([127.0.0.1]:50872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp8zr-0002kn-M2 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 11:50:28 -0500 Received: from mail.eclipso.de ([217.69.254.104]:48890) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp8zn-0002jd-RL for 76705@debbugs.gnu.org; Mon, 03 Mar 2025 11:50:25 -0500 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1741020616; bh=5r18aB00HA/bJRxgte83HaTXJWadxrT0OGTgXijq/2k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RizlV5RPzPrkR14C4vO4XTFbUKAYxSKQ7jj0bhQkiv8srK3nVxFdxO0YlNSYiF0Ca VPFHLCuUE8YoUMIYmkOv2TEi1JO2Gofp/mDYdJoQK+gY92AJp0K3IhVeodwEFveSos esNVV2I6IHTWtAmdrM6eGhWdsRgL8zKBBP6NqJoSOJzbGxMogskazXwla4JlC3NVBu RvllDrvqSbPezXMQWp9tbEn4YDb6qSPvxMKgedZkj9F4BmNN4lY8ZjTaE7KBntkzJM pPopL2VwAyYcjXKV8CnE+ddK+zbMZrpMxnct1a+3CDNSMiAZI9Urks9N4A+nV1XgmY zvakdlBpfG08A== To: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash In-Reply-To: <87wmd69jt3.fsf@protonmail.com> (Pip Cet's message of "Mon, 03 Mar 2025 16:11:03 +0000") References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> Date: Mon, 03 Mar 2025 17:50:15 +0100 Message-ID: <87tt8a83eg.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76705 Cc: 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Pip Cet writes: >> $ objdump -h dump | grep " load" | wc >> 9237 64659 747221 > > Hmm. Is it possible that increases by a factor of 6 during a collection? > How large is the core file? $ ls -lh total 2.8G -rw-rw-r-- 1 oscar oscar 2.8G Mar 3 16:46 dump >>> What is the output of >>> >>> cat /proc/sys/vm/max_map_count >>> >>> ? It is 65530 here, >> >> Same here. > > I set it to 4096, and that crashed my MPS Emacs when I started a > collection (which is when the mprotect calls happen), so running against > this limit during a collection is my current best theory. > > If this is indeed an issue, we might have to increase ARENA_GRAIN_SIZE, > or submit a patch to MPS... > > However, I would still like to see errno = ENOMEM to be sure :-) Trying to follow Eli's hint: (gdb) ptype errno type = int (gdb) whatis errno type = int (gdb) p errno $1 = 25 ENOEM here is: /usr/include/asm-generic/errno-base.h 16:#define ENOMEM 12 /* Out of memory */ >>> Thanks! This means that it was actually ProtSet which aborted, and since >>> it doesn't show up in the backtrace it must have tail-called the >>> assertion function. Can you disassemble ProtSet just to make sure that >>> we're looking at an mprotect failure here? >> >> (gdb) disass/s ProtSet >> Dump of assembler code for function ProtSet: >> 0x0000556e0edcf8b0 <+0>: push %r12 >> 0x0000556e0edcf8b2 <+2>: mov %edx,%r12d >> 0x0000556e0edcf8b5 <+5>: push %rbp >> 0x0000556e0edcf8b6 <+6>: mov %rdi,%rbp > > Hmm. You've compiled MPS without -fno-omit-frame-pointer. I think > (hope!) that's safe as only references created outside of MPS can pin > objects... Sorry! Next build will use -fno-omit-frame-pointer. _________________________________________________________________ ________________________________________________________ Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 14:57:44 2025 Received: (at 76705) by debbugs.gnu.org; 3 Mar 2025 19:57:44 +0000 Received: from localhost ([127.0.0.1]:52234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpBv5-0007lX-KB for submit@debbugs.gnu.org; Mon, 03 Mar 2025 14:57:43 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:53661) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tpBv0-0007l8-R8 for 76705@debbugs.gnu.org; Mon, 03 Mar 2025 14:57:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741031851; x=1741291051; bh=ObX6ns4K/K895ckT9McCXnh2afTlthrQz2bt3rUZXzQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=mBKOC0nEXuTr2NnlP+sbPgD0Y6zqNtspQCUeLCoimsceY8XYjyAtmK5mR43o5plgL SuUc40OATJiwJanF624HRCbxLX9Rjf7Zi1R/gewlNxvQGHUkn4FWv7kRePnb9xIil3 ZQPxTfC/au4+qnkgBP3ip/MbcAWv+XVSUrvsoAJMafDQ6gGEvEhy77jqs1Wy0S+F6J E0FSAMoTTYr1vmIx99ZbWx2fQcNt80qbgiYKrb+p9FlNBMz4vx+TYNSRRDnXQna8PJ XRmR0u/DeYRsFn72YDCBTxMaMQeEqn3b8xS6dN3iVA3XLkYpQSgiPqLx7K1vPdOb5k V/1yYe2WRrWAA== Date: Mon, 03 Mar 2025 19:57:27 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash Message-ID: <87ldtlanw8.fsf@protonmail.com> In-Reply-To: <87tt8a83eg.fsf@telefonica.net> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> <87tt8a83eg.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7412d5b8a0f5c7bd3c1eeb93fea7eaa98514da26 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 76705 Cc: 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > Pip Cet writes: > >>> $ objdump -h dump | grep " load" | wc >>> 9237 64659 747221 >> >> Hmm. Is it possible that increases by a factor of 6 during a collection? >> How large is the core file? > > $ ls -lh > total 2.8G > -rw-rw-r-- 1 oscar oscar 2.8G Mar 3 16:46 dump That looks potentially large enough for my theory that we ran out into the max_map_count limit. MPS_ARGS_ADD (args, MPS_KEY_ARENA_GRAIN_SIZE, 64 * 1024); wouldn't fix the problem, but by extrapolation we'd only hit it when the Emacs session reaches ~20 GB :-) (I originally added that line to my local tree for performance reasons, but I'm not sure about the impact on weak objects in particular.) If you have the time and inclination, you could reduce /proc/sys/vm/max_map_count and see what kind of Emacs crash you get, but as it's a system-wide property, that might not be a good idea if other important stuff is on the machine... >>>> What is the output of >>>> >>>> cat /proc/sys/vm/max_map_count >>>> >>>> ? It is 65530 here, >>> >>> Same here. >> >> I set it to 4096, and that crashed my MPS Emacs when I started a >> collection (which is when the mprotect calls happen), so running against >> this limit during a collection is my current best theory. >> >> If this is indeed an issue, we might have to increase ARENA_GRAIN_SIZE, >> or submit a patch to MPS... >> >> However, I would still like to see errno =3D ENOMEM to be sure :-) > > Trying to follow Eli's hint: > > (gdb) ptype errno > type =3D int > (gdb) whatis errno > type =3D int > (gdb) p errno > $1 =3D 25 That's ENOTTY here, which is unlikely to be what mprotect returned, so possibly another error (most likely something during the abort tried an ioctl?) So if it's the mprotect thing, what do we do? Is glibc running into the same problem when it uses mmap for malloc? >>>> Thanks! This means that it was actually ProtSet which aborted, and sin= ce >>>> it doesn't show up in the backtrace it must have tail-called the >>>> assertion function. Can you disassemble ProtSet just to make sure tha= t >>>> we're looking at an mprotect failure here? >>> >>> (gdb) disass/s ProtSet >>> Dump of assembler code for function ProtSet: >>> 0x0000556e0edcf8b0 <+0>: push %r12 >>> 0x0000556e0edcf8b2 <+2>: mov %edx,%r12d >>> 0x0000556e0edcf8b5 <+5>: push %rbp >>> 0x0000556e0edcf8b6 <+6>: mov %rdi,%rbp >> >> Hmm. You've compiled MPS without -fno-omit-frame-pointer. I think >> (hope!) that's safe as only references created outside of MPS can pin >> objects... > > Sorry! Next build will use -fno-omit-frame-pointer. No reason to apologize, I'm not even sure it's a problem. just something I noticed in the assembly listing. Pip From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 04 14:04:51 2025 Received: (at 76705) by debbugs.gnu.org; 4 Mar 2025 19:04:51 +0000 Received: from localhost ([127.0.0.1]:60987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpXZS-0007cJ-S0 for submit@debbugs.gnu.org; Tue, 04 Mar 2025 14:04:51 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:37391) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tpXZO-0007bw-Rm for 76705@debbugs.gnu.org; Tue, 04 Mar 2025 14:04:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741115079; x=1741374279; bh=mu6D1m6WzdKelX7Qkvs/ZIaaHWKI2O5mJO9MvEaJ0l0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=To0P4nKQYjKkGAcBybT5khlsasK1JB7u14MG78Qn4tcLwaTgdjqP7r1CMmoEYN5c6 XmsApFnr1LXzCQO9pArg5u0uSSIMLh4IZUUNJ86RVy34LNyXU92gni585Xs6nCpKv4 Ap49nWFBmQJ2jpN3N1K3KyBJ0MJnomRldQgxM48GSmm8Jtk2ZkLTPgzZbcaTKsvqF8 +Om2Et7KfLw7g3CDOUweeKGYG9v397mHdzddu2qh1XYpT0WKy7XWsstInMHO8YeEsk sNyhwqrAknjlZn2xmzuNCS/uwaiVREaje0cHEYvXnHoOFdVtnWg/Dhhe1Ziq/vy7FI QpRzwqFTF7FyA== Date: Tue, 04 Mar 2025 19:04:34 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= , =?utf-8?Q?Gerd_M=C3=B6llmann?= , Helmut Eller , Eli Zaretskii From: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash Message-ID: <87frjsaa8u.fsf@protonmail.com> In-Reply-To: <87tt8a83eg.fsf@telefonica.net> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> <87tt8a83eg.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4e12edfc8f0548e16c4508d0a24134f42d91570d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76705 Cc: 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd, Helmut, Eli: See https://github.com/Ravenbrook/mps/issues/304 for the description of a Linux-specific MPS issue that currently causes hard crashes when we create "too many" mappings for the Linux kernel (this is purely a kernel issue, so no GNU/ prefix here), which causes 'mprotect' to fail with ENOMEM. We have to find a workaround for this. Increasing AREA_GRAIN_SIZE may delay running into the problem, or there might be a way to handle a failed mprotect call and at least recover the Emacs session, but ultimately the maximum safe size of an Emacs session appears to be ARENA_GRAIN_SIZE * /proc/sys/vm/max_map_count, or about 512 MB of MPS memory (minus whatever mappings libraries, malloc, and mmap require). That's obviously not sufficient. One open question is whether Linux is actually capable of merging adjacent mappings when they're 'mprotect'ed to have the same permissions. Looking at /proc//maps shows things like these: 7fff7044a000-7fff70462000 rwxp 00000000 00:00 0 7fff70462000-7fff70463000 ---p 00000000 00:00 0 7fff70463000-7fff7047a000 rwxp 00000000 00:00 0 7fff7047a000-7fff7049e000 rwxp 00000000 00:00 0 7fff7049e000-7fff704b0000 rwxp 00000000 00:00 0 which appears to indicate at least some mappings cannot be merged that way. However, the line count of this /proc file is reduced significantly by calling M-x igc-collect, indicating that sometimes mappings are merged. I'll have a closer look at the MPS code to come up with a plausible workaround, but any ideas would be appreciated! Pip Cet writes: > =C3=93scar Fuentes writes: > >> Pip Cet writes: >> >>>> $ objdump -h dump | grep " load" | wc >>>> 9237 64659 747221 >>> >>> Hmm. Is it possible that increases by a factor of 6 during a collection= ? >>> How large is the core file? >> >> $ ls -lh >> total 2.8G >> -rw-rw-r-- 1 oscar oscar 2.8G Mar 3 16:46 dump > > That looks potentially large enough for my theory that we ran out into > the max_map_count limit. > > MPS_ARGS_ADD (args, MPS_KEY_ARENA_GRAIN_SIZE, 64 * 1024); > > wouldn't fix the problem, but by extrapolation we'd only hit it when the > Emacs session reaches ~20 GB :-) > > (I originally added that line to my local tree for performance reasons, > but I'm not sure about the impact on weak objects in particular.) > > If you have the time and inclination, you could reduce > /proc/sys/vm/max_map_count and see what kind of Emacs crash you get, but > as it's a system-wide property, that might not be a good idea if other > important stuff is on the machine... So I decided to experiment with this on a VM, and I'm now convinced it's what happens. I've reported this bug on GitHub at https://github.com/Ravenbrook/mps/issues/304 (complete copy follows because GitHub sometimes will refuse to let you even see posts without an account, so we should document things in public forums as well as GitHub's closed database). While running out of maps is an unfortunate situation, it is not necessarily unfixable: if Linux coalesces maps that become identical again, we can just eagerly trigger memory barriers until we're back in a situation where not too many maps exist. Some care needs to be taken to ensure we don't call 'malloc' while doing so, because 'malloc' can itself create new mappings. However, it seems reasonable to ultimately contact the Linux kernel folks about setting this limit to a more reasonable value (and working around whatever optimizations depend on it being so low), or doing the same thing for the more popular distros. Here's the GitHub report: (I'm working on the feature/igc branch of GNU Emacs which adds MPS as a gar= bage collector. You haven't heard much from us since things are going very = well generally, and it's usually our fault when they don't) However, we've now seen several reports which indicate the `mprotect` call = in `protix.c`:`ProtSet` failed, which leads to unreachable code being reach= ed and an Emacs crash: ``` /* .assume.mprotect.base */ result =3D mprotect((void *)base, (size_t)AddrOffset(base, limit), flags)= ; if (MAYBE_HARDENED_RUNTIME && result !=3D 0 && errno =3D=3D EACCES && (flags & PROT_WRITE) && (flags & PROT_EXEC)) { /* Apple Hardened Runtime is enabled, so that we cannot have * memory that is simultaneously writable and executable. Handle * this by dropping the executable part of the request. See * for details. */ prot_all =3D PROT_READ | PROT_WRITE; result =3D mprotect((void *)base, (size_t)AddrOffset(base, limit), flag= s & prot_all); } if (result !=3D 0) NOTREACHED; ``` `protix.txt` says this: ``` _`.fun.set.assume.mprotect`: We assume that the call to ``mprotect()`` always succeeds. We should always call the function with valid arguments (aligned, references to mapped pages, and with an access that is compatible with the access of the underlying object). ``` Our current theory is that this assumption is violated on Linux, which keep= s a maximum number of contiguous maps in `/proc/sys/vm/max_map_count`, with= the default at 65530. The way it appears to work is that when a single pag= e in a large contiguous map is `mprotect`ed to be different than its neighb= ors, that map turns into three maps for the purposes of the max_map_count l= imit, and `mprotect` eventually returns `ENOMEM`. Experiments with lowering the `max_map_count` limit in a virtual machine ap= pear to be consistent with that theory, because it causes Emacs crashes muc= h like the ones that were reported by our users. Pip From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 04 22:54:16 2025 Received: (at 76705) by debbugs.gnu.org; 5 Mar 2025 03:54:16 +0000 Received: from localhost ([127.0.0.1]:33869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpfpo-0004Hd-5g for submit@debbugs.gnu.org; Tue, 04 Mar 2025 22:54:16 -0500 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:44403) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tpfpk-0004HO-SH for 76705@debbugs.gnu.org; Tue, 04 Mar 2025 22:54:13 -0500 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-abf57138cfaso706590066b.1 for <76705@debbugs.gnu.org>; Tue, 04 Mar 2025 19:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741146846; x=1741751646; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=edwSLKMtjnp7UbbOhAlTz7StLtbsbRPY0E+cW2rlhXQ=; b=lZgayrwBf5rSfWihMElIW9TB+JfBQSLjzEQfpz1lIH+liIDTYK6XDcDvSpa6gRiZH7 XbrTTVS7Qd43TY07BrwHZsdxIMkl1nSsy3XHJle8vS9tWx+c+ziQaQAxzS0SU+2S+UH2 krxJr/1Rmmq7MHOx4JBE/Q4IRQF7Z4oMdbmvNjGNnvHocUaXFlg1oH94K4Fv8pq1tg2I xuRzaeU405Tk4/7qeScUNWcwJsSPD2r5NBKPl7pqVqEp7YH4YLWYYGhEetyvpbGwlMOG nLc1s/zyaKzroAF7UJPtenQ/0CdBMk/cetGQLrRydUFmwIajW8VQD8DHtsU/nU3DwVOS LPLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741146846; x=1741751646; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=edwSLKMtjnp7UbbOhAlTz7StLtbsbRPY0E+cW2rlhXQ=; b=pqAr1lNvFK6CkxxxXfmWkFWrljphMMSbxWTezM40dGr9MZwJb3gZSDM9B2Zw3W71BN yJJstS+5ofNJ1rniNWitkuqKLmMthKX+eniKJzX8/dNq92wAn1ECC9MJ6+KZiSdW52aS fIl8dNlcWH96FH5a+D5eGzP/P4uBgigsbjxoIW4Ka+BBQtj7NJOMdkXVdmrV0kNWIBnE cOPVDo6bKNFRRP9tOTJXyDJgVCTdhVzrjyH1iwPqIwbG41SDh63Sqkc2wJEMeP1T1ihp 99GlRq5TJmJmJ6MzX9b35T9lMNebeLzgi+u3HkAg/slBx5nEDmpa8Kg0wcU9dfHvlQ6Q /UZw== X-Forwarded-Encrypted: i=1; AJvYcCVq4xb4FqDMlPBumxDVnBEdmbYPmYMlmjhD4trT19aNnPBB1wo0yXme8FJyfGx9KnF0BzApfw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyOKzKPpjFwMu3hnH8IavTQEx3UiPfzVIFFXp3M+YTqJJC6tsQt 7FzNz2fAqizB6yDUSu1RBiGif7k7ybUIn0da/k4Jf0SHQa1C2jvW3NbToA== X-Gm-Gg: ASbGncsrzeVCI/HHVMnC6vjNKz7pl0h8cmAsL4kalrmzktxZ0O1UKa0O5FNuHtPhFME RCEbOXOE+AZORid1hSz57Vh1yPP1mTfzJ1MUDFaFIrFqiajfUoc5Cb2ce5UrcFlzkZVExNVIMvC GXiwxNX4lF1iHjdWF8QNENCq57846nQ2TOM1gFhqabBFGkc7WOMpjWIICL/OUgajSkH+JhculCq pqb345ROAkWYMnrjBenve/PzOc2rlRfd8nOanQheCwks47tnnBQTsPe1BKJdPcUJOhRKXeNYBFX 2mJptLmk7kYHd4l5+K+P+KOJhEjO+4zAcLM+r75pz7FVfr+aK5UZ/mifWb8QSpNo4rIE+Yvh2vl W45ACJ4DZz67KWjWRfTtH3ivGI8DQUko3NBnIfoUMx3olMT3Fd1VJuQ== X-Google-Smtp-Source: AGHT+IG1zB6yWvzxE7E01a1iVazO+JwH+Wl1pc0RfWpsIpGiYaI76506+hZ17YUp9Ucf8N2olR3VNQ== X-Received: by 2002:a17:907:72ca:b0:abf:6dc7:b536 with SMTP id a640c23a62f3a-ac20e152a9amr166119266b.44.1741146846031; Tue, 04 Mar 2025 19:54:06 -0800 (PST) Received: from pro2 (p200300e0b72c2200f9f6105787af3087.dip0.t-ipconnect.de. [2003:e0:b72c:2200:f9f6:1057:87af:3087]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac09b586d87sm390378866b.40.2025.03.04.19.54.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Mar 2025 19:54:05 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash In-Reply-To: <87frjsaa8u.fsf@protonmail.com> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> <87tt8a83eg.fsf@telefonica.net> <87frjsaa8u.fsf@protonmail.com> Date: Wed, 05 Mar 2025 04:54:03 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76705 Cc: 76705@debbugs.gnu.org, =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , Helmut Eller X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > Gerd, Helmut, Eli: > > See https://github.com/Ravenbrook/mps/issues/304 for the description of > a Linux-specific MPS issue that currently causes hard crashes when we > create "too many" mappings for the Linux kernel (this is purely a kernel > issue, so no GNU/ prefix here), which causes 'mprotect' to fail with > ENOMEM. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 05 07:34:59 2025 Received: (at 76705) by debbugs.gnu.org; 5 Mar 2025 12:34:59 +0000 Received: from localhost ([127.0.0.1]:35994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpnxi-0007VJ-Ui for submit@debbugs.gnu.org; Wed, 05 Mar 2025 07:34:59 -0500 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:42346) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tpnxg-0007Uy-4c for 76705@debbugs.gnu.org; Wed, 05 Mar 2025 07:34:57 -0500 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e4ce6e3b8cso1265927a12.1 for <76705@debbugs.gnu.org>; Wed, 05 Mar 2025 04:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741178089; x=1741782889; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=+dQzGFYTRhAR4q9Z8T6WKuYExCtrXDn58jA/NagaIdg=; b=gTCitCwwQ32texj5I6LNY1986klGYUrK+BMO7zzkEf577me47LV0sL5nWKdEbRtMG1 LzNRF0g5EKuGKZEfgj2x3G3+/Ne7T6FcMc5k5UgIeJUW1XsldD6dJNmv5N7RiRKf9FJU AZ2jKK28JsCd7J280Ov66UNTqrYrGbiet0tSKeqL2V20I2U+5vw0XMMYbYRmGUCCv2fJ Bn4W/7xSZzTogl1rhtd10pvkhjfp6jscqp0VK5biiRhBdOmNynsuPCmGeAZx7xu4y2bW MW30+u6e9obDqf/z+GjldgqXgP/PCvfJUzqWRhY9NHO759uKNDPfa/DR8SCnhtDop6Cf UyqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741178089; x=1741782889; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+dQzGFYTRhAR4q9Z8T6WKuYExCtrXDn58jA/NagaIdg=; b=VUD6b7//JLX3SWTvmae2Aprx2qsjQzhQA/VM5xXRC5VkwyqXkhjwKOOcuNnWWlnyGK /zD6jEAxs2NinvRxJRG+BckpOlQAifvEtbPcN+RCFRbRGbmkUhWwSMNeecS+nriy+oQg HBH2yJAlwyHuJi180QACOMhtgUSSk0o3J/7UL0DHOD596Gu/Dfe5W+KPfMFW/OMW2NNq 3WGtmgSnkbyEOFE/uN/XSg5TSqSYg7p30dcgTxKMlRdtWr2Apa/7cyQZcHFSCjvGCTLE ssZM78UMmbdbxGE25c4FoqYcqLstZNVW62iDkk9bLrBPERNEDi3JD2xqlNQRP5JsN8T6 8XuQ== X-Forwarded-Encrypted: i=1; AJvYcCVc9evIW6B6dxLWZz6qCHUAlJuCf1gUK7SkNKjMDC4UXJUedc0WG/FeGDf5H4kc5ExlHdwHmA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzzZ51+ObGXTvrG1/6R0rstdT4BiuoS6f0ZngADaP7szPKzC97G 6qv+UdM+vaxbuZSqAPXZL9rIYAXYKWQC3q0eD3EbhaxiFzAYgTPAYb4FaQ== X-Gm-Gg: ASbGncuoeIBTQJ2Dmrhw5iEJO8k08Qy7ZMVR+JyGcLD995pbOn7kDJF2xivweDOhCi+ GLidrkoa19IwYV6uzOMcYinZNkLD/46SgtBDJ2WFbt4vgndxbOu3u+Q6Cleh7aS6sUz5v/ftaeb jeH29aW7LbKdDM93lVGHU9qZyuSf6qVi9e5d46neXEPn24oSYqshmsta8bDLuYYUeZUddEnOwUi cLD+R/vgWUNhc4/xrwFwc8ydYb7sP2jaHz1jmZSZtZF4i612QTB4lC2UsR3vsT3+sGYRIspV21F vKGdLTN8Soz6Lnk9X4V4FUjxIry5kD3WpjsJjnUHTb1EPmsuSEvE95CjWzCVAY0YdwBwlNy6SXs Mzw== X-Google-Smtp-Source: AGHT+IHY4lHpJBjwh0oiHU+uTzLAmfKC6z+jIo9ZFFdr5EeyH8xmap1b/iOikdrlPkJSUijJDvWCgQ== X-Received: by 2002:a05:6402:1ed6:b0:5e0:8a27:cd36 with SMTP id 4fb4d7f45d1cf-5e584e56313mr6930198a12.8.1741178089090; Wed, 05 Mar 2025 04:34:49 -0800 (PST) Received: from caladan (dialin-233080.rol.raiffeisen.net. [195.254.233.80]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e4c3fb633bsm9570090a12.63.2025.03.05.04.34.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 04:34:48 -0800 (PST) From: Helmut Eller To: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash In-Reply-To: <87frjsaa8u.fsf@protonmail.com> (Pip Cet's message of "Tue, 04 Mar 2025 19:04:34 +0000") References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> <87tt8a83eg.fsf@telefonica.net> <87frjsaa8u.fsf@protonmail.com> Date: Wed, 05 Mar 2025 13:34:47 +0100 Message-ID: <877c53y7tk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76705 Cc: Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= , =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --=-=-= Content-Type: text/plain On Tue, Mar 04 2025, Pip Cet wrote: > Gerd, Helmut, Eli: > > See https://github.com/Ravenbrook/mps/issues/304 for the description of > a Linux-specific MPS issue that currently causes hard crashes when we > create "too many" mappings for the Linux kernel (this is purely a kernel > issue, so no GNU/ prefix here), which causes 'mprotect' to fail with > ENOMEM. For me, this code ;; -*- lexical-binding: t -*- (defun test () (let* ((npages 120000) (pages (make-vector npages nil))) (dotimes (i npages) (aset pages i (make-vector (/ 4096 2) 0))) (message "nmaps: %s" (shell-command-to-string (format "wc -l /proc/%d/maps" (emacs-pid)))) (dotimes (i npages) (when (zerop (% i 2)) (let ((page (aref pages i))) (aset page 0 1)))))) crashes with: protix.c:117: Emacs fatal error: assertion failed: unreachable code Though this seems to require >4GB. > We have to find a workaround for this. We could emit a warning (similar to [1]) and telling users to increase max_map_count. E.g. if COMMIT_LIMIT / PAGE_SIZE > max_map_count. Increasing max_map_size seems pretty harmless[2] and the reason[3] why it is so low, seems to be some no-longer relevant limit for core dumps[3]. We could also set COMMIT_LIMIT to max_map_count / PAGE_SIZE, so that MPS tries harder to reuse memory. Beside issue #288[4], we would likely see situations where MPS gets slower and slower because it can free some memory but not enough to make much progress on non-GC tasks. [1] https://alchemistsimulator.github.io/howtos/workarounds/max-map-count/index.html#symptoms [2] https://www.suse.com/support/kb/doc/?id=000016692 [3] https://github.com/torvalds/linux/blob/v5.18/include/linux/mm.h#L178 [4] https://github.com/Ravenbrook/mps/issues/288 > Increasing AREA_GRAIN_SIZE may delay running into the problem, or there > might be a way to handle a failed mprotect call and at least recover the > Emacs session, but ultimately the maximum safe size of an Emacs session > appears to be ARENA_GRAIN_SIZE * /proc/sys/vm/max_map_count, or about > 512 MB of MPS memory (minus whatever mappings libraries, malloc, and > mmap require). That's obviously not sufficient. My guess is that AREA_GRAIN_SIZE is used for mmap/mmunmap but the memory barriers always work at page granularity. I could be wrong of course. > One open question is whether Linux is actually capable of merging > adjacent mappings when they're 'mprotect'ed to have the same > permissions. That's easy to verify with the attached C code. Without the second call to change_protection, the number mappings increases until the process aborts. Helmut --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=mprot.c #include #include #include #include #include #include #include typedef uintptr_t w; struct segment { w *start, len; }; void check_errno (bool b, int err) { if (!b) { fprintf (stderr, "%d (%s)\n", err, strerror (err)); abort (); } } struct segment map_segment (w length, int prot) { w *start = mmap (NULL, length, prot, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); check_errno (start != MAP_FAILED, errno); struct segment s = { start, length }; return s; } void change_protection (void *start, w len, int prot) { int err = mprotect (start, len, prot); check_errno (err == 0, errno); } int main (int argc, char *argv[]) { argc = argc; argv = argv; w page_size = 4096; w npages = 1024 * 1024; struct segment s = map_segment (page_size * npages, PROT_NONE); for (w i = 0; i < npages; i += 2) { change_protection ((char *)s.start + i * page_size, page_size, PROT_READ); change_protection ((char *)s.start + i * page_size, page_size, PROT_NONE); } return 0; } --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 05 08:46:17 2025 Received: (at 76705) by debbugs.gnu.org; 5 Mar 2025 13:46:17 +0000 Received: from localhost ([127.0.0.1]:36188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpp4i-0005WQ-I4 for submit@debbugs.gnu.org; Wed, 05 Mar 2025 08:46:17 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:36907) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tpp4g-0005WB-2Q for 76705@debbugs.gnu.org; Wed, 05 Mar 2025 08:46:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741182365; x=1741441565; bh=3RYQ/nYhk13uUh8EjQDnFpN3ld/OovUWivz+yf2saio=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=MpIhYJzZXzBdmuthyBnuQ8E9sMwX/REa4QXwH/1OAp3qcHqw/a0eUks06aP4MtUyE sv2sI5T2uvuSJsJJ1X51t2/vDv3iG16ROXyYVHj/izxZdXgdkjUPXDYWkAPM7WbSO1 3KMHOuN0uo0533BeAwOvxJwXVdv5nA1UKjXpE4j4lXPrqSE9wUmmkPuNTWNnjTjw0c QxaVokVVnXvduY4i/VSyREXCFYUOd4GwxtccQuuFYgI2DK0y7WUbLks30kzS/2NEHz pCagIqZ4uuLzL+cmA6aMfXNcx2In+mNIVX55+v8XFfkQN7fFa5WHek4145QwJl0Pea GSlL+K/P9QOFA== Date: Wed, 05 Mar 2025 13:45:59 +0000 To: Helmut Eller From: Pip Cet Subject: Re: bug#76705: 31.0.50; igc: crash Message-ID: <87ikon3824.fsf@protonmail.com> In-Reply-To: <877c53y7tk.fsf@gmail.com> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> <87tt8a83eg.fsf@telefonica.net> <87frjsaa8u.fsf@protonmail.com> <877c53y7tk.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b0a15a0f649035c5385b14a6f3e6d14a2efc99a6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76705 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , =?utf-8?Q?=C3=93scar_Fuentes?= , Eli Zaretskii , 76705@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Helmut Eller" writes: > On Tue, Mar 04 2025, Pip Cet wrote: > >> Gerd, Helmut, Eli: >> >> See https://github.com/Ravenbrook/mps/issues/304 for the description of >> a Linux-specific MPS issue that currently causes hard crashes when we >> create "too many" mappings for the Linux kernel (this is purely a kernel >> issue, so no GNU/ prefix here), which causes 'mprotect' to fail with >> ENOMEM. > > For me, this code > ;; -*- lexical-binding: t -*- > > (defun test () > (let* ((npages 120000) > =09 (pages (make-vector npages nil))) > (dotimes (i npages) > (aset pages i (make-vector (/ 4096 2) 0))) > (message "nmaps: %s" > =09 (shell-command-to-string > =09 (format "wc -l /proc/%d/maps" (emacs-pid)))) > (dotimes (i npages) > (when (zerop (% i 2)) > =09(let ((page (aref pages i))) > =09 (aset page 0 1)))))) > > crashes with: > protix.c:117: Emacs fatal error: assertion failed: unreachable code > > Though this seems to require >4GB. 3.23user 4.00system 0:07.56elapsed 95%CPU (0avgtext+0avgdata 3723392maxresi= dent)k with some modifications. So it seems that ARENA_GRAIN_SIZE doesn't influence it (it seems to be ProtGranularity, which is bad news). And, as far as I know, we don't know how eagerly MPS installs memory barriers and what the worst case is. >> We have to find a workaround for this. > > We could emit a warning (similar to [1]) and telling users to increase > max_map_count. E.g. if COMMIT_LIMIT / PAGE_SIZE > max_map_count. Yeah, that's the worst case: tell people to reconfigure their kernel so they can run Emacs. > We could also set COMMIT_LIMIT to max_map_count / PAGE_SIZE, so that MPS ^ *, I hope. Yes, that's the 256 MB/512 MB limit for MPS memory, except it's actually less because of all the non-MPS map entries. > tries harder to reuse memory. Beside issue #288[4], we would likely > see situations where MPS gets slower and slower because it can free some > memory but not enough to make much progress on non-GC tasks. Doesn't seem much better, and it assumes all of the maps are available for MPS to use, which isn't true: thousands of them are already used for malloc, dlopen(), and mmap. >> Increasing AREA_GRAIN_SIZE may delay running into the problem, or there >> might be a way to handle a failed mprotect call and at least recover the >> Emacs session, but ultimately the maximum safe size of an Emacs session >> appears to be ARENA_GRAIN_SIZE * /proc/sys/vm/max_map_count, or about >> 512 MB of MPS memory (minus whatever mappings libraries, malloc, and >> mmap require). That's obviously not sufficient. > > My guess is that AREA_GRAIN_SIZE is used for mmap/mmunmap but the memory > barriers always work at page granularity. I could be wrong of course. That seems correct given your code above, and considering Size ProtGranularity(void) { /* Individual pages can be protected. */ return PageSize(); } which we could also override, of course. >> One open question is whether Linux is actually capable of merging >> adjacent mappings when they're 'mprotect'ed to have the same >> permissions. > > That's easy to verify with the attached C code. Without the second call > to change_protection, the number mappings increases until the process > aborts. The question was whether removing a memory barrier (making the protection the same as the surrounding mappings) would *reliably* reduce the number of mappings again or *sometimes* keep redundant adjacent mappings with the same protection. Mappings are coalesced sometimes, as we know, but sometimes redundant mappings show up in /proc/$$/maps, so it doesn't seem to be reliable (and even if it were reliable now, which Linux versions does that apply to?) Thanks a lot for your investigation! I'm afraid this looks a lot like we need to modify MPS to be usable for ordinary Emacs use cases, to keep track of the number of mapping discontinuities (I don't even know how to get that number short of reading /proc/$$/maps and counting lines) and give up and trigger some memory barriers if it gets too close to the limit. Pip From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 06 02:52:22 2025 Received: (at 76705) by debbugs.gnu.org; 6 Mar 2025 07:52:22 +0000 Received: from localhost ([127.0.0.1]:41281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tq61l-0001iP-Qa for submit@debbugs.gnu.org; Thu, 06 Mar 2025 02:52:22 -0500 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:53659) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tq61j-0001i8-7w for 76705@debbugs.gnu.org; Thu, 06 Mar 2025 02:52:19 -0500 Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-abf3d64849dso47691466b.3 for <76705@debbugs.gnu.org>; Wed, 05 Mar 2025 23:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741247533; x=1741852333; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=vk3iq116P/ALT/20SoIM6PGXpMTffUDE3DjqjVMTGII=; b=RjuzWcexHku+zlx0yOJuLCQorzNJlJ4sSmkURSOpCxvEllfaR21LQrCw6EOjMQgMi5 HDBjnvRgXvMS2PL1b0B1dQm7i/CadsrTB6jKlWVcNtGb76aRjS888qiwUoXeoejJOWjp tF51m6MmGrewJRK9r+0LReyxX7ryJ5ykBo/pjhkMykwHMvQlF8s/wgsRi4zP+b95KmjL NrjujPbFTJMYx0odSrckCdfj00nkOOYGuGrq55Y3sXnh2S5CKhjZzKwlhojDhyWCGQj7 ID+o5rWPBkwcy162rTa1p6jB2s1mpUGCuPnaY+OIscg28nAmOg47CH5OZV99v5/G+d1i 15zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741247533; x=1741852333; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vk3iq116P/ALT/20SoIM6PGXpMTffUDE3DjqjVMTGII=; b=SOJuWtbPHjIcuTae/0/dYmOvTjB8QS+7EY410xm/TdST34Dx/LLZ0v3PSs5RMbu1lk /vVWeIx075qro5eiWRt0UJ3lizKkzRlQL+YI7FLPOwSZmz1HdZuLm+vxwjb804unvwRL f2FGUI6/dBgbnwGoPYDHBrhKd/868EDUz4Nf7cLJmTqi7dqQMaDs6tEEffMyY9E+l3dg YgkbZxPBcIv41PHGFL6TIcs99bNySVd1SFibJ5wti3V1V/Pbe/HqW/WgaxZbGzN3SMH0 RTItVErC19m9OW47SNQPs/j+gdcUPAEHejbzGAiK0opUtawrYoais+Krz9mN7xSirX7F wO6w== X-Forwarded-Encrypted: i=1; AJvYcCX0WykT8ukT7ffAJUzQIb1n/gEuIhHFozii/zjfFhIDHj7FPfgcgFdWifHhWW8GAEcQx4VPlA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw0fnEJwnEpwXq3jjQyH88vdC11MUoumQMBFtI6qzxItCbVyPvg lITs9sbCnytuQ+PaH70axICPVpQYJEM0+NPv2wjHNjM7i6t/E0RozLFVqg== X-Gm-Gg: ASbGncuU/nJYGG6niFQKbMKE1sleipkhlV/GRxW/r+tHH2LQX4KSILnGBts6LJN4PLp XTUV74bDCjDtP0aKIwcz3kIq/tPN1kselFKWTTYfp10stIVq8HWL9/1hj8Iwgrh4i3Zc9AIN+T+ eOZUD2mw6UkT3zIcmo2QyIrl6JAU3sthWl0QVd/jk64p7IxOYgCR2cBDg6MAjLc2oPlmBNK838j oRXItWMcp722FomC28K86VbuxOgVkga189kBlFX4JhxdoCgjaYantj5vm6l19XMzCXvXVbjtaCF mN875GrqUMX5fnIdo3Wj4HQdP8q/E0k5wSnkSrB2ggpyRAgmvVuNxFAxr/5aGPb0ULUaisdbRTI e7ewgt/ihJJu32yIoTGNQYGoulj7cEpRBFL/KZpuXf99xL3oGXqBsAw== X-Google-Smtp-Source: AGHT+IGsyh+2tW7ZR82ZTZQvXh6o8FoxFpuWdXxoOUTbzy0dT07Otp7tR0OLjUOf4r1+ytESqKr+xQ== X-Received: by 2002:a05:6402:430a:b0:5dc:7374:261d with SMTP id 4fb4d7f45d1cf-5e59f394dafmr14755927a12.7.1741247532404; Wed, 05 Mar 2025 23:52:12 -0800 (PST) Received: from pro2 (p200300e0b7334300c1279b63d7ea1fda.dip0.t-ipconnect.de. [2003:e0:b733:4300:c127:9b63:d7ea:1fda]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e5c747219dsm547862a12.20.2025.03.05.23.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 23:52:11 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Helmut Eller Subject: Re: bug#76705: 31.0.50; igc: crash In-Reply-To: <877c53y7tk.fsf@gmail.com> References: <87ikor9nso.fsf@telefonica.net> <87h64axs3p.fsf@protonmail.com> <878qpm9mig.fsf@telefonica.net> <87wmd6w2id.fsf@protonmail.com> <871pve9krh.fsf@telefonica.net> <87wmd69jt3.fsf@protonmail.com> <87tt8a83eg.fsf@telefonica.net> <87frjsaa8u.fsf@protonmail.com> <877c53y7tk.fsf@gmail.com> Date: Thu, 06 Mar 2025 08:52:10 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76705 Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Pip Cet , 76705@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Helmut Eller writes: > For me, this code > ;; -*- lexical-binding: t -*- > > (defun test () > (let* ((npages 120000) > (pages (make-vector npages nil))) > (dotimes (i npages) > (aset pages i (make-vector (/ 4096 2) 0))) > (message "nmaps: %s" > (shell-command-to-string > (format "wc -l /proc/%d/maps" (emacs-pid)))) > (dotimes (i npages) > (when (zerop (% i 2)) > (let ((page (aref pages i))) > (aset page 0 1)))))) > > crashes with: > protix.c:117: Emacs fatal error: assertion failed: unreachable code FWIW, no problem on macOS with the program above (page size = 16K). I drove it up to using ca. 16G memory which went down to normal again after igc-collect. Alas, I don't know how to see details of the VM.