Package: emacs;
Reported by: Óscar Fuentes <oscarfv <at> eclipso.eu>
Date: Mon, 3 Mar 2025 04:33:04 UTC
Severity: normal
Found in version 31.0.50
To reply to this bug, email your comments to 76705 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 04:33:05 GMT) Full text and rfc822 format available.Óscar Fuentes <oscarfv <at> eclipso.eu>:bug-gnu-emacs <at> gnu.org.
(Mon, 03 Mar 2025 04:33:05 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: bug-gnu-emacs <at> gnu.org Subject: 31.0.50; igc: crash Date: Sun, 02 Mar 2025 21:32:07 +0100
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=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0)
at ./nptl/pthread_kill.c:44
#1 0x00007f487751de2f in __pthread_kill_internal (threadid=<optimized out>, signo=6)
at ./nptl/pthread_kill.c:78
#2 0x00007f48774c9d02 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/posix/raise.c:26
#3 0x0000556e0ead9d68 in terminate_due_to_signal
(sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> 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=<optimized out>, line=<optimized out>, msg=<optimized out>)
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 <at> entry=88, type=type <at> 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 <at> entry=9, nwords_lisp=nwords_lisp <at> entry=0, nwords_zero=nwords_zero <at> entry=0, tag=tag <at> entry=PVEC_HASH_TABLE) at ../../emacs/src/igc.c:4277
#14 0x0000556e0ec65bae in allocate_pseudovector
(memlen=memlen <at> entry=9, lisplen=lisplen <at> entry=0, zerolen=zerolen <at> entry=0, tag=tag <at> 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 <hashtest_equal>, size=2, weak=<optimized out>)
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=<optimized out>) 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=<optimized out>) 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=<optimized out>) 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=<optimized out>) 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=<optimized out>) at ../../emacs/src/json.c:1655
#37 0x0000556e0ed2aef5 in json_parse (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1705
#38 Fjson_parse_buffer (nargs=<optimized out>, args=<optimized out>) at ../../emacs/src/json.c:1812
#39 0x0000556e0ecd9cba in exec_byte_code
(fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../emacs/src/lisp.h:2290
#40 0x0000556e0ec8d858 in Ffuncall (nargs=nargs <at> entry=3, args=0x7ffd3b15d3d0)
at ../../emacs/src/eval.c:3115
#41 0x0000556e0ec8dbe4 in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd3b15d460)
at ../../emacs/src/eval.c:2787
#42 0x0000556e0ec8df63 in apply1 (fn=<optimized out>, arg=<optimized out>) at ../../emacs/src/eval.c:3003
#43 0x0000556e0ec88fa2 in internal_condition_case_1
(bfun=bfun <at> entry=0x556e0ece67b0 <read_process_output_call>, arg=0x7f4767c4805b, handlers=handlers <at> entry=0xa8, hfun=hfun <at> entry=0x556e0ece66f0 <read_process_output_error_handler>) at ../../emacs/src/eval.c:1650
#44 0x0000556e0ece93a6 in read_and_dispose_of_process_output
(p=<optimized out>, 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 <at> entry=0x7f4761f7966d, channel=channel <at> entry=25)
at ../../emacs/src/process.c:6291
#46 0x0000556e0ecf0c8b in wait_reading_process_output
(time_limit=time_limit <at> entry=0, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0)
at ../../emacs/src/process.c:5972
#47 0x0000556e0ec06a2f in kbd_buffer_get_event
(kbp=<synthetic pointer>, used_mouse_menu=<optimized out>, end_time=<optimized out>)
at ../../emacs/src/keyboard.c:4115
#48 read_event_from_main_queue
(end_time=end_time <at> entry=0x0, local_getcjmp=local_getcjmp <at> entry=0x7ffd3b15dd20, used_mouse_menu=used_mouse_menu <at> entry=0x7ffd3b15e00b) at ../../emacs/src/keyboard.c:2336
#49 0x0000556e0ec0c5b6 in read_decoded_event_from_main_queue
(end_time=<optimized out>, local_getcjmp=<optimized out>, prev_event=<optimized out>, used_mouse_menu=<optimized out>) at ../../emacs/src/keyboard.c:2399
#50 read_char
(commandflag=1, map=map <at> entry=0x7f4766b23feb, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7ffd3b15e00b, end_time=end_time <at> entry=0x0) at ../../emacs/src/keyboard.c:3031
#51 0x0000556e0ec0f651 in read_key_sequence
(keybuf=keybuf <at> entry=0x7ffd3b15e140, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false, 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 <at> entry=0x556e0ec11320 <command_loop_1>, handlers=handlers <at> entry=0xa8, hfun=hfun <at> entry=0x556e0ec04560 <cmd_error>) at ../../emacs/src/eval.c:1626
#54 0x0000556e0ebfc43e in command_loop_2 (handlers=handlers <at> entry=0xa8) at ../../emacs/src/keyboard.c:1174
#55 0x0000556e0ec88e52 in internal_catch
(tag=tag <at> entry=0x14dd0, func=func <at> entry=0x556e0ebfc410 <command_loop_2>, arg=arg <at> 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=<optimized out>, 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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 11:39:02 GMT) Full text and rfc822 format available.Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 11:38:01 +0000
Óscar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> 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=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0)
> at ./nptl/pthread_kill.c:44
> #1 0x00007f487751de2f in __pthread_kill_internal (threadid=<optimized out>, signo=6)
> at ./nptl/pthread_kill.c:78
> #2 0x00007f48774c9d02 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/posix/raise.c:26
> #3 0x0000556e0ead9d68 in terminate_due_to_signal
> (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> 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=<optimized out>, line=<optimized out>, msg=<optimized out>)
> 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=size <at> entry=88, type=type <at> 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 <at> entry=9, nwords_lisp=nwords_lisp <at> entry=0, nwords_zero=nwords_zero <at> entry=0, tag=tag <at> entry=PVEC_HASH_TABLE) at ../../emacs/src/igc.c:4277
> #14 0x0000556e0ec65bae in allocate_pseudovector
> (memlen=memlen <at> entry=9, lisplen=lisplen <at> entry=0, zerolen=zerolen <at> entry=0, tag=tag <at> 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 <hashtest_equal>, size=2, weak=<optimized out>)
> 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=<optimized out>) 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=<optimized out>) 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=<optimized out>) 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=<optimized out>) 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=<optimized out>) at ../../emacs/src/json.c:1655
> #37 0x0000556e0ed2aef5 in json_parse (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1705
> #38 Fjson_parse_buffer (nargs=<optimized out>, args=<optimized out>) at ../../emacs/src/json.c:1812
> #39 0x0000556e0ecd9cba in exec_byte_code
> (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
> at ../../emacs/src/lisp.h:2290
> #40 0x0000556e0ec8d858 in Ffuncall (nargs=nargs <at> entry=3, args=0x7ffd3b15d3d0)
> at ../../emacs/src/eval.c:3115
> #41 0x0000556e0ec8dbe4 in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd3b15d460)
> at ../../emacs/src/eval.c:2787
> #42 0x0000556e0ec8df63 in apply1 (fn=<optimized out>, arg=<optimized out>) at ../../emacs/src/eval.c:3003
> #43 0x0000556e0ec88fa2 in internal_condition_case_1
> (bfun=bfun <at> entry=0x556e0ece67b0 <read_process_output_call>, arg=0x7f4767c4805b, handlers=handlers <at> entry=0xa8, hfun=hfun <at> entry=0x556e0ece66f0 <read_process_output_error_handler>) at ../../emacs/src/eval.c:1650
> #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output
> (p=<optimized out>, 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)
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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 11:39:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 15:13:02 GMT) Full text and rfc822 format available.Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: Pip Cet <pipcet <at> protonmail.com> Cc: Óscar Fuentes <bug-gnu-emacs <at> gnu.org>, 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 16:12:07 +0100
Pip Cet <pipcet <at> protonmail.com> writes:
> Óscar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> 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=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0)
at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {0}}
ret = <optimized out>
#1 0x00007f487751de2f in __pthread_kill_internal (threadid=<optimized out>, signo=6)
at ./nptl/pthread_kill.c:78
#2 0x00007f48774c9d02 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x0000556e0ead9d68 in terminate_due_to_signal
(sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ../../emacs/src/emacs.c:463
#4 0x0000556e0ed16d73 in set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1023
old_state = <optimized out>
old_state = <optimized out>
#5 set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1002
old_state = <optimized out>
#6 igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>)
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 <at> entry=88, type=type <at> entry=IGC_OBJ_VECTOR, ap=0x7f4868001900) at ../../emacs/src/igc.c:4095
res = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
p = 0x0
#12 0x0000556e0ed1afa8 in alloc (size=88, type=IGC_OBJ_VECTOR) at ../../emacs/src/igc.c:4008
#13 igc_alloc_pseudovector
(nwords_mem=nwords_mem <at> entry=9, nwords_lisp=nwords_lisp <at> entry=0, nwords_zero=nwords_zero <at> entry=0, tag=tag <at> entry=PVEC_HASH_TABLE) at ../../emacs/src/igc.c:4277
client_size = 88
v = <optimized out>
#14 0x0000556e0ec65bae in allocate_pseudovector
(memlen=memlen <at> entry=9, lisplen=lisplen <at> entry=0, zerolen=zerolen <at> entry=0, tag=tag <at> 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 <hashtest_equal>, size=2, weak=<optimized out>)
at ../../emacs/src/fns.c:4897
h = <optimized out>
#17 0x0000556e0ed2a96a in json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1608
value = <optimized out>
h = <optimized out>
c = <optimized out>
first = 4019
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
key = <optimized out>
value = <optimized out>
key = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
value = <optimized out>
nc = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
value = <optimized out>
h = <optimized out>
i = <optimized out>
hash = <optimized out>
key = <optimized out>
value = <optimized out>
i = <optimized out>
#18 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
#19 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
at ../../emacs/src/json.c:1522
c = <optimized out>
c = <optimized out>
#20 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
key = 0x7f476c1a7d74
value = <optimized out>
cdr = 0x7ffd3b15cab0
c = 34
--Type <RET> for more, q to quit, c to continue without paging--
first = 4011
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
key = <optimized out>
value = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
value = <optimized out>
h = <optimized out>
i = <optimized out>
hash = <optimized out>
key = <optimized out>
value = <optimized out>
i = <optimized out>
#21 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
#22 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454
element = <optimized out>
cdr = 0x7ffd3b15cb28
c = <optimized out>
first = 4010
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
element = <optimized out>
nc = <optimized out>
number_of_elements = <optimized out>
i = <optimized out>
#23 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
#24 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
at ../../emacs/src/json.c:1522
c = <optimized out>
c = <optimized out>
#25 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
key = 0x7f476c1a7254
value = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
cdr = 0x7ffd3b15cb90
c = 34
first = 4010
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
key = <optimized out>
value = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
value = <optimized out>
h = <optimized out>
i = <optimized out>
hash = <optimized out>
key = <optimized out>
value = <optimized out>
i = <optimized out>
#26 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
c5 = <optimized out>
c6 = <optimized out>
#27 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454
element = <optimized out>
cdr = 0x7ffd3b15cc08
c = <optimized out>
first = 4009
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
element = <optimized out>
nc = <optimized out>
number_of_elements = <optimized out>
i = <optimized out>
#28 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
#29 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
at ../../emacs/src/json.c:1522
c = <optimized out>
c = <optimized out>
#30 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
--Type <RET> for more, q to quit, c to continue without paging--
key = 0x7f476c1a5bcc
value = <optimized out>
cdr = 0x7ffd3b15cc70
c = 34
first = 4009
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
key = <optimized out>
value = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
value = <optimized out>
h = <optimized out>
i = <optimized out>
hash = <optimized out>
key = <optimized out>
value = <optimized out>
i = <optimized out>
#31 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
c2 = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
#32 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454
element = <optimized out>
cdr = 0x7ffd3b15cce8
c = <optimized out>
first = 4
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
element = <optimized out>
nc = <optimized out>
number_of_elements = <optimized out>
i = <optimized out>
#33 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
#34 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
at ../../emacs/src/json.c:1522
c = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
c = <optimized out>
#35 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
key = 0x7f4767c488ec
value = <optimized out>
cdr = 0x7ffd3b15cd50
c = 34
first = 0
result = 0x0
c = <optimized out>
first = <optimized out>
result = <optimized out>
cdr = <optimized out>
key = <optimized out>
value = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
key = <optimized out>
value = <optimized out>
nc = <optimized out>
value = <optimized out>
h = <optimized out>
i = <optimized out>
hash = <optimized out>
key = <optimized out>
value = <optimized out>
i = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
#36 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
c2 = <optimized out>
c3 = <optimized out>
c4 = <optimized out>
c5 = <optimized out>
c6 = <optimized out>
#37 0x0000556e0ed2aef5 in json_parse (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1705
#38 Fjson_parse_buffer (nargs=<optimized out>, args=<optimized out>) at ../../emacs/src/json.c:1812
count = {bytes = <optimized out>}
conf = {object_type = <optimized out>, array_type = <optimized out>, null_object = <optimized out>, false_object = <optimized out>}
p = {input_current = 0x556e3342596e "}],\"detail\":\"struct\",\"kind\":23,\"name\":\"ra_struct_0xAB71CCE7u<true>\",\"range\":{\"end\":{\"character\":62,\"line\":9091},\"start\":{\"character\":0,\"line\":9091}},\"selectionRange\":{\"end\":{\"character\":10,\"line\":9091"..., input_begin = 0x556e32ee1f60 "{\"id\":17456,\"jsonrpc\":\"2.0\",\"result\":[{\"children\":[{\"detail\":\"lp0::PluginInfoAdder\",\"kind\":13,\"name\":\"ppa8\",\"range\":{\"end\":{\"character\":33,\"line\":7},\"start\":{\"character\":0,\"line\":7}},\"selectionRange\":"..., input_end = 0x556e33733f5e "", secondary_input_begin = 0x0, secondary_input_end = 0x0, current_line = 1, current_column = 5519886, point_of_current_line = 0, available_depth = 9993, conf = {object_type = json_object_hashtable, array_type = json_array_array, null_object = 0x0, false_object = 0x0}, additional_bytes_count = 0, internal_object_workspace = {0x7f4767c48874, 0x110c2, 0x7f4767c4889c, 0x7f4767c488c4, 0x7f4767c4972d, 0x7f4767c4c63d, 0x7f4767c4cd4d, 0x7f4767c4f9c5, 0x7f4767c53005, 0x7f4767c53ef5, 0x7f4767c54df5, 0x7f4767c55ce5, 0x7f4767c58bf5, 0x7f4767c59ae5, 0x7f4767c5c76d, 0x7f4767c5dd9d, 0x7f4767c60c8d, 0x7f4767c61b7d, 0x7f4767c62a6d, 0x7f4767c6395d, 0x7f4767c6689d, 0x7f4767c6778d, 0x7f4767c6868d, 0x7f4767c6957d, 0x7f4767c6c48d, 0x7f4767c6d37d, 0x7f4767c6e26d, 0x7f4767c6f15d, 0x7f4767c7009d, 0x7f4767c70f8d, 0x7f4767c71e7d, 0x7f4767c74d7d, 0x7f4767c75c6d, 0x7f4767c76b7d, 0x7f4767c77a6d, 0x7f4767c7a9ad, 0x7f4767c7b89d, 0x7f4767c7c78d, 0x7f4767c7d67d, 0x7f4767c80575, 0x7f4767c81465, 0x7f4767c8237d, 0x7f4767c8326d, 0x7f4767c8615d, 0x7f4767c8704d, 0x7f4767c87f3d, 0x7f4767c88e5d, 0x7f4767c89d4d, 0x7f4767c8cc8d, 0x7f4767c8cd64, 0x7f4767c8d4dd, 0x7f4767c--Type <RET> for more, q to quit, c to continue without paging--
8d4f4, 0x7f4767c8d51c, 0x7f4767c8d544, 0x56, 0x7f4767c8d56c, 0x7f4767c8d594, 0x7f4767c8d5bc, 0x7f4767c8d805, 0x7f4767c8d8c4, 0x7f4767c8d93d, 0x7f4767c8d9fc, 0x2, 0x21e}, object_workspace = 0x556e374c43e0, object_workspace_size = 4096, object_workspace_current = 4023, internal_byte_workspace = "9091acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177\000\000\000\000\000\000\000\000\000\000\020\370\302\016nU\000\000\b\000\000\000\000\000\000\000\020\321\025;\375\177\000\000\t\000\000\000\000\000\000\000\310\321\025;\375\177\000\000\000\000\000\000\000\000\000\000\020\370\302\016nU\000\000\b\000\000\000\000\000\000\000p\321\025;\375\177\000\000"..., byte_workspace = 0x7ffd3b15d050 "9091acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177", byte_workspace_end = 0x7ffd3b15d250 "P\320\025;\375\177", byte_workspace_current = 0x7ffd3b15d054 "acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177"}
begin = <optimized out>
end = <optimized out>
secondary_begin = <optimized out>
secondary_end = <optimized out>
result = <optimized out>
byte = <optimized out>
position = <optimized out>
#39 0x0000556e0ecd9cba in exec_byte_code
(fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../emacs/src/lisp.h:2290
call_nargs = 6
call_fun = <optimized out>
count1 = {bytes = <optimized out>}
val = <optimized out>
call_args = 0x7f486347f078
original_fun = 0x29da650d7dc0
--Type <RET> for more, q to quit, c to continue without paging--
op = 6
type = <optimized out>
targets = {0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecda0c8 <exec_byte_code+2056>, 0x556e0ecda0c3 <exec_byte_code+2051>, 0x556e0ecda0be <exec_byte_code+2046>, 0x556e0ecd9aa3 <exec_byte_code+483>, 0x556e0ecd9aa3 <exec_byte_code+483>, 0x556e0ecda080 <exec_byte_code+1984>, 0x556e0ecda042 <exec_byte_code+1922>, 0x556e0ecdc03a <exec_byte_code+10106>, 0x556e0ecdc035 <exec_byte_code+10101>, 0x556e0ecdc030 <exec_byte_code+10096>, 0x556e0ecdc02b <exec_byte_code+10091>, 0x556e0ecd9add <exec_byte_code+541>, 0x556e0ecd9ae0 <exec_byte_code+544>, 0x556e0ecdc01e <exec_byte_code+10078>, 0x556e0ecdc03f <exec_byte_code+10111>, 0x556e0ecdbec6 <exec_byte_code+9734>, 0x556e0ecdbec1 <exec_byte_code+9729>, 0x556e0ecdbebc <exec_byte_code+9724>, 0x556e0ecdbeb7 <exec_byte_code+9719>, 0x556e0ecd9a39 <exec_byte_code+377>, 0x556e0ecd9a40 <exec_byte_code+384>, 0x556e0ecdbe9d <exec_byte_code+9693>, 0x556e0ecdbeaa <exec_byte_code+9706>, 0x556e0ecdbe4b <exec_byte_code+9611>, 0x556e0ecdbe46 <exec_byte_code+9606>, 0x556e0ecdbe41 <exec_byte_code+9601>, 0x556e0ecdbe3c <exec_byte_code+9596>, 0x556e0ecd9d98 <exec_byte_code+1240>, 0x556e0ecd9da0 <exec_byte_code+1248>, 0x556e0ecdbe5d <exec_byte_code+9629>, 0x556e0ecdbe50 <exec_byte_code+9616>, 0x556e0ecdbe1d <exec_byte_code+9565>, 0x556e0ecdbe18 <exec_byte_code+9560>, 0x556e0ecdbe13 <exec_byte_code+9555>, 0x556e0ecdbe0e <exec_byte_code+9550>, 0x556e0ecd9b3d <exec_byte_code+637>, 0x556e0ecd9b40 <exec_byte_code+640>, 0x556e0ecdbe2f <exec_byte_code+9583>, 0x556e0ecdbe22 <exec_byte_code+9570>, 0x556e0ecdbdef <exec_byte_code+9519>, 0x556e0ecdbdea <exec_byte_code+9514>, 0x556e0ecdbde5 <exec_byte_code+9509>, 0x556e0ecdbde0 <exec_byte_code+9504>, 0x556e0ecd9d4b <exec_byte_code+1163>, 0x556e0ecd9d50 <exec_byte_code+1168>, 0x556e0ecdbe01 <exec_byte_code+9537>, 0x556e0ecdbdf4 <exec_byte_code+9524>, 0x556e0ecdb9fa <exec_byte_code+8506>, 0x556e0ecdba2e <exec_byte_code+8558>, 0x556e0ecdbab0 <exec_byte_code+8688>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecdb84e <exec_byte_code+8078>, 0x556e0ecdb7db <exec_byte_code+7963>, 0x556e0ecdb794 <exec_byte_code+7892>, 0x556e0ecdb74d <exec_byte_code+7821>, 0x556e0ecdb708 <exec_byte_code+7752>, 0x556e0ecdbf47 <exec_byte_code+9863>, 0x556e0ecdbf07 <exec_byte_code+9799>, 0x556e0ecdb6d6 <exec_byte_code+7702>, 0x556e0ecdbfa3 <exec_byte_code+9955>, 0x556e0ecdbecb <exec_byte_code+9739>, 0x556e0ecdb696 <exec_byte_code+7638>, 0x556e0ecdb666 <exec_byte_code+7590>, 0x556e0ecdb626 <exec_byte_code+7526>, 0x556e0ecdb5e9 <exec_byte_code+7465>, 0x556e0ecdb5a8 <e--Type <RET> for more, q to quit, c to continue without paging--
xec_byte_code+7400>, 0x556e0ecdb532 <exec_byte_code+7282>, 0x556e0ecdb4a7 <exec_byte_code+7143>, 0x556e0ecdb412 <exec_byte_code+6994>, 0x556e0ecdb3e2 <exec_byte_code+6946>, 0x556e0ecdb3b2 <exec_byte_code+6898>, 0x556e0ecdb372 <exec_byte_code+6834>, 0x556e0ecdb332 <exec_byte_code+6770>, 0x556e0ecdb2f2 <exec_byte_code+6706>, 0x556e0ecdb2ae <exec_byte_code+6638>, 0x556e0ecdb274 <exec_byte_code+6580>, 0x556e0ecdb23a <exec_byte_code+6522>, 0x556e0ecdb200 <exec_byte_code+6464>, 0x556e0ecdb15e <exec_byte_code+6302>, 0x556e0ecdb102 <exec_byte_code+6210>, 0x556e0ecdb0a8 <exec_byte_code+6120>, 0x556e0ecdb04e <exec_byte_code+6030>, 0x556e0ecdaff4 <exec_byte_code+5940>, 0x556e0ecdaf9a <exec_byte_code+5850>, 0x556e0ecdaf40 <exec_byte_code+5760>, 0x556e0ecdaee8 <exec_byte_code+5672>, 0x556e0ecdae8b <exec_byte_code+5579>, 0x556e0ecdae33 <exec_byte_code+5491>, 0x556e0ecdaddb <exec_byte_code+5403>, 0x556e0ecdad83 <exec_byte_code+5315>, 0x556e0ecdad2a <exec_byte_code+5226>, 0x556e0ecdac39 <exec_byte_code+4985>, 0x556e0ecd9de9 <exec_byte_code+1321>, 0x556e0ecdac09 <exec_byte_code+4937>, 0x556e0ecdabd4 <exec_byte_code+4884>, 0x556e0ecdab44 <exec_byte_code+4740>, 0x556e0ecdaafa <exec_byte_code+4666>, 0x556e0ecdaaca <exec_byte_code+4618>, 0x556e0ecdaa98 <exec_byte_code+4568>, 0x556e0ecdaa66 <exec_byte_code+4518>, 0x556e0ecdaa2c <exec_byte_code+4460>, 0x556e0ecda9fa <exec_byte_code+4410>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecda9c8 <exec_byte_code+4360>, 0x556e0ecda996 <exec_byte_code+4310>, 0x556e0ecda964 <exec_byte_code+4260>, 0x556e0ecda932 <exec_byte_code+4210>, 0x556e0ecda900 <exec_byte_code+4160>, 0x556e0ecda8d0 <exec_byte_code+4112>, 0x556e0ecd9de9 <exec_byte_code+1321>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecda88d <exec_byte_code+4045>, 0x556e0ecda85d <exec_byte_code+3997>, 0x556e0ecda82c <exec_byte_code+3948>, 0x556e0ecda7eb <exec_byte_code+3883>, 0x556e0ecda7aa <exec_byte_code+3818>, 0x556e0ecda779 <exec_byte_code+3769>, 0x556e0ecda748 <exec_byte_code+3720>, 0x556e0ecda707 <exec_byte_code+3655>, 0x556e0ecda6c6 <exec_byte_code+3590>, 0x556e0ecda685 <exec_byte_code+3525>, 0x556e0ecda652 <exec_byte_code+3474>, 0x556e0ecda621 <exec_byte_code+3425>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecdbbbf <exec_byte_code+8959>, 0x556e0ecdbd6e <exec_byte_code+9390>, 0x556e0ecdbfdf <exec_byte_code+10015>, 0x556e0ecdbd2f <exec_byte_code+9327>, 0x556e0ecdbcf3 <exec_byte_code+9267>, 0x556e0ecdbcb7 <exec_byte_code+9207>, 0x556e0ecdbc1d <exec_byte_code+9053>, 0x556e0ecdbbf8 <exec_byte_code+9016>, 0x556e0ecdbe6a <exec_byte_code+9642>, 0x556e0ecdbb9a <exec_byte_code+8922>, 0x556e0ecdbb37 <exec_byte_code+8823>, 0x556e0ecdbb02 <exec_byte_code+8770>, 0x556e0ecdbabb <exec_byte_code+8699>, 0x556e0ecdb9a5 <exec_byte_code+8421>, 0x556e0ecdb961 <exec_byte_code+8353>, 0x556e0ecdb917 <exec_byte_code+8279>, 0x556e0ecdb8ac <exec_byte_code+8172>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x--Type <RET> for more, q to quit, c to continue without paging--
556e0ecda5dc <exec_byte_code+3356>, 0x556e0ecda5ab <exec_byte_code+3307>, 0x556e0ecda57a <exec_byte_code+3258>, 0x556e0ecda549 <exec_byte_code+3209>, 0x556e0ecda518 <exec_byte_code+3160>, 0x556e0ecda4d7 <exec_byte_code+3095>, 0x556e0ecda496 <exec_byte_code+3030>, 0x556e0ecda455 <exec_byte_code+2965>, 0x556e0ecda414 <exec_byte_code+2900>, 0x556e0ecda3ad <exec_byte_code+2797>, 0x556e0ecda36c <exec_byte_code+2732>, 0x556e0ecda32b <exec_byte_code+2667>, 0x556e0ecda2fa <exec_byte_code+2618>, 0x556e0ecda2ae <exec_byte_code+2542>, 0x556e0ecda262 <exec_byte_code+2466>, 0x556e0ecda224 <exec_byte_code+2404>, 0x556e0ecda1e6 <exec_byte_code+2342>, 0x556e0ecda1ab <exec_byte_code+2283>, 0x556e0ecdacd2 <exec_byte_code+5138>, 0x556e0ecdac83 <exec_byte_code+5059>, 0x556e0ecda13b <exec_byte_code+2171>, 0x556e0ecda0cd <exec_byte_code+2061>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecdb562 <exec_byte_code+7330>, 0x556e0ecdb1ba <exec_byte_code+6394>, 0x556e0ecdab8e <exec_byte_code+4814>, 0x556e0ecd9ffc <exec_byte_code+1852>, 0x556e0ecd9fb6 <exec_byte_code+1782>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecd9f7d <exec_byte_code+1725>, 0x556e0ecd9f19 <exec_byte_code+1625>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0eadee50 <exec_byte_code[cold]>, 0x556e0ecd9edf <exec_byte_code+1567> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x556e0ee8a8f8 <main_thread+504>
top = 0x7f486347f070
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f4761f7f9a8
--Type <RET> for more, q to quit, c to continue without paging--
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
saved_quitcounter = 1 '\001'
saved_vectorp = 0x7f4761f7f9a8
saved_bytestr_data = 0x7f4782ba94e8 "\300\306â!\203\020"
result = <optimized out>
#40 0x0000556e0ec8d858 in Ffuncall (nargs=nargs <at> entry=3, args=0x7ffd3b15d3d0)
at ../../emacs/src/eval.c:3115
count = {bytes = <optimized out>}
val = <optimized out>
#41 0x0000556e0ec8dbe4 in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd3b15d460)
at ../../emacs/src/eval.c:2787
i = <optimized out>
funcall_nargs = 3
funcall_args = <optimized out>
spread_arg = <optimized out>
fun = <optimized out>
sa_avail = <optimized out>
sa_count = {bytes = 352}
numargs = <optimized out>
retval = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
#42 0x0000556e0ec8df63 in apply1 (fn=<optimized out>, arg=<optimized out>) at ../../emacs/src/eval.c:3003
#43 0x0000556e0ec88fa2 in internal_condition_case_1
(bfun=bfun <at> entry=0x556e0ece67b0 <read_process_output_call>, arg=0x7f4767c4805b, handlers=handlers <at> entry=0xa8, hfun=hfun <at> entry=0x556e0ece66f0 <read_process_output_error_handler>) at ../../emacs/src/eval.c:1650
val = <optimized out>
c = 0x7f4873e850a0
#44 0x0000556e0ece93a6 in read_and_dispose_of_process_output
(p=<optimized out>, 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
outstream = 0x7f4761f7f1ed
text = 0x7f4767c48004
outer_running_asynch_code = true
waiting = -1
outstream = <optimized out>
text = <optimized out>
outer_running_asynch_code = <optimized out>
waiting = <optimized out>
tem = <optimized out>
#45 read_process_output (proc=proc <at> entry=0x7f4761f7966d, channel=channel <at> entry=25)
at ../../emacs/src/process.c:6291
nbytes = 335897
p = 0x7f4761f79668
coding = <optimized out>
carryover = <optimized out>
readmax = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
count = {bytes = <optimized out>}
odeactivate = 0x0
chars = <optimized out>
sa_avail = <optimized out>
sa_count = {bytes = <optimized out>}
#46 0x0000556e0ecf0c8b in wait_reading_process_output
(time_limit=time_limit <at> entry=0, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0)
at ../../emacs/src/process.c:5972
nread = <optimized out>
process_skipped = <optimized out>
wrapped = <optimized out>
channel_start = 26
child_fd = <optimized out>
last_read_channel = 25
channel = <optimized out>
nfds = <optimized out>
Available = {fds_bits = {33554432, 0 <repeats 15 times>}}
Writeok = {fds_bits = {0 <repeats 16 times>}}
check_write = <optimized out>
check_delay = <optimized out>
no_avail = <optimized out>
xerrno = 11
proc = 0x7f4761f7966d
timeout = {tv_sec = 0, tv_nsec = 10000000}
end_time = {tv_sec = 0, tv_nsec = 139949216517785}
timer_delay = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
--Type <RET> for more, q to quit, c to continue without paging--
got_output_end_time = {tv_sec = 0, tv_nsec = -1}
wait = <optimized out>
got_some_output = <optimized out>
prev_wait_proc_nbytes_read = 0
retry_for_async = <optimized out>
count = {bytes = <optimized out>}
now = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
#47 0x0000556e0ec06a2f in kbd_buffer_get_event
(kbp=<synthetic pointer>, used_mouse_menu=<optimized out>, end_time=<optimized out>)
at ../../emacs/src/keyboard.c:4115
do_display = <optimized out>
obj = <optimized out>
str = <optimized out>
had_pending_selection_requests = false
had_pending_conversion_events = false
obj = <optimized out>
str = <optimized out>
had_pending_selection_requests = <optimized out>
had_pending_conversion_events = <optimized out>
now = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
duration = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
do_display = <optimized out>
tty = <optimized out>
first = <optimized out>
event = <optimized out>
copy = {kind = <optimized out>, dpyinfo = <optimized out>, requestor = <optimized out>, selection = <optimized out>, target = <optimized out>, property = <optimized out>, time = <optimized out>}
--Type <RET> for more, q to quit, c to continue without paging--
f = <optimized out>
frame = <optimized out>
focus = <optimized out>
pinch_dx = <optimized out>
pinch_dy = <optimized out>
pinch_angle = <optimized out>
maybe_event = <optimized out>
f = <optimized out>
movement_frame = <optimized out>
bar_window = <optimized out>
part = <optimized out>
x = <optimized out>
y = <optimized out>
t = <optimized out>
frame = <optimized out>
#48 read_event_from_main_queue
(end_time=end_time <at> entry=0x0, local_getcjmp=local_getcjmp <at> entry=0x7ffd3b15dd20, used_mouse_menu=used_mouse_menu <at> entry=0x7ffd3b15e00b) at ../../emacs/src/keyboard.c:2336
c = 0x0
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 93931182793087, 0, 0, 3, 93931182213056, 140725594737840}}}}
kb = 0x556e2eb38850
count = {bytes = <optimized out>}
#49 0x0000556e0ec0c5b6 in read_decoded_event_from_main_queue
(end_time=<optimized out>, local_getcjmp=<optimized out>, prev_event=<optimized out>, used_mouse_menu=<optimized out>) at ../../emacs/src/keyboard.c:2399
nextevt = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
frame = <optimized out>
terminal = <optimized out>
events = {0xd5b8, 0x0, 0x7f476553cee3, 0x1, 0x7ffd3b15dd00, 0x556e0ed04dbf <lookup_char_property+495>, 0x0, 0xd5b8, 0xecd6, 0x3b35, 0x7f478e045568, 0x7f478e04556d, 0x7ffd3b15de00, 0x556e0ec7a70c <Fget_pos_property+812>, 0xecd6, 0x7f478e045568}
n = 0
events = {<optimized out> <repeats 16 times>}
n = <optimized out>
nextevt = <optimized out>
frame = <optimized out>
terminal = <optimized out>
meta_key = <optimized out>
coding = <optimized out>
i = <optimized out>
c = <optimized out>
modifier = <optimized out>
src = {<optimized out> <repeats 16 times>}
dest = {<optimized out> <repeats 80 times>}
i = <optimized out>
p = <optimized out>
c = <optimized out>
modifier = <optimized out>
#50 read_char
(commandflag=1, map=map <at> entry=0x7f4766b23feb, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7ffd3b15e00b, end_time=end_time <at> entry=0x0) at ../../emacs/src/keyboard.c:3031
c = 0x0
local_getcjmp = {{__jmpbuf = {139948951031040, -1218948282702943986, 93931718281296, 0, 15403, 0, -1--Type <RET> for more, q to quit, c to continue without paging--
218948282577114866, -5029668301387126514}, __mask_was_saved = 0, __saved_mask = {__val = {128, 0, 0, 50456, 93931184418448, 140725594742272, 93931182793475, 139948330862256, 15, 140725594742224, 93931182711373, 0, 46017145348552, 140725594742384, 93931182330548, 54712}}}}
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 93931182793087, 0, 0, 3, 93931182213056, 140725594737840}}}}
tem = <optimized out>
save = <optimized out>
previous_echo_area_message = 0x0
also_record = 0x0
reread = false
recorded = false
polling_stopped_here = true
orig_kboard = 0x556e2eb38850
retry = <optimized out>
jmpcount = {bytes = <optimized out>}
c_volatile = 0x0
#51 0x0000556e0ec0f651 in read_key_sequence
(keybuf=keybuf <at> entry=0x7ffd3b15e140, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false, disable_text_conversion_p=false)
at ../../emacs/src/keyboard.c:10790
interrupted_kboard = 0x556e2eb38850
interrupted_frame = <optimized out>
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
keys_local_start = 0
new_binding = <optimized out>
count = {bytes = <optimized out>}
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = 0x7f4766b23feb
first_unbound = 31
mock_input = <optimized out>
used_mouse_menu_history = {false <repeats 30 times>}
fkey = {parent = 0x7f4867545ab3, map = <optimized out>, start = 0, end = 0}
keytran = {parent = 0x7f4873e5c0d3, map = <optimized out>, start = 0, end = 0}
indec = {parent = 0x7f4867545a9b, map = <optimized out>, start = 0, end = 0}
shift_translated = <optimized out>
delayed_switch_frame = <optimized out>
original_uppercase = <optimized out>
original_uppercase_position = <optimized out>
disabled_conversion = <optimized out>
starting_buffer = <optimized out>
fake_prefixed_keys = 0x0
first_event = 0x0
second_event = <optimized out>
#52 0x0000556e0ec114d8 in command_loop_1 () at ../../emacs/src/keyboard.c:1435
cmd = <optimized out>
keybuf = {0xb2, 0x1d6, 0x1de, 0x0, 0x139e8, 0x556e0ee16e90, 0x7ffd3b15e1e0, 0x556e0ec8a303 <unbind_to+563>, 0x7f476b4ebe33, 0x7ffd3b15e200, 0xc, 0x139e8, 0x38, 0x7f47bc51a55d, 0x29da64f38c80, 0x7f476b4ebe33, 0x60, 0x7ffd3b15e200, 0x7ffd3b15e3b8, 0xffffffffffffffff, 0x7ffd3b15e260, 0x556e0ec046bd <cmd_error+349>, 0x--Type <RET> for more, q to quit, c to continue without paging--
0, 0x0, 0xcb00, 0x556e0ee16e90, 0x7ffd3b15e280, 0x556e0ec8a303 <unbind_to+563>, 0x0, 0xcbe0}
i = <optimized out>
last_pt = <optimized out>
prev_modiff = 10245
prev_buffer = 0x7f478e045568
#53 0x0000556e0ec88f26 in internal_condition_case
(bfun=bfun <at> entry=0x556e0ec11320 <command_loop_1>, handlers=handlers <at> entry=0xa8, hfun=hfun <at> entry=0x556e0ec04560 <cmd_error>) at ../../emacs/src/eval.c:1626
val = <optimized out>
c = 0x7f486598df68
#54 0x0000556e0ebfc43e in command_loop_2 (handlers=handlers <at> entry=0xa8) at ../../emacs/src/keyboard.c:1174
val = <optimized out>
#55 0x0000556e0ec88e52 in internal_catch
(tag=tag <at> entry=0x14dd0, func=func <at> entry=0x556e0ebfc410 <command_loop_2>, arg=arg <at> entry=0xa8)
at ../../emacs/src/eval.c:1305
val = <optimized out>
c = <optimized out>
#56 0x0000556e0ebfc3d3 in command_loop () at ../../emacs/src/keyboard.c:1152
#57 0x0000556e0ec040d6 in recursive_edit_1 () at ../../emacs/src/keyboard.c:760
count = {bytes = <optimized out>}
val = <optimized out>
#58 0x0000556e0ec04488 in Frecursive_edit () at ../../emacs/src/keyboard.c:843
count = {bytes = <optimized out>}
buffer = <optimized out>
#59 0x0000556e0eae3296 in main (argc=<optimized out>, argv=0x7ffd3b15e5d8) at ../../emacs/src/emacs.c:2580
stack_bottom_variable = 0x7f4877671ac0 <main_arena>
old_argc = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 1
temacs = 0x0
attempt_load_pdump = <optimized out>
only_version = false
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
>> #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 <shieldFlushEntries+56>
0x0000556e0edd0b9c <+28>: test %rdi,%rdi
0x0000556e0edd0b9f <+31>: jne 0x556e0edd0cd0 <shieldFlushEntries+336>
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 # 0x556e0ed6b2d0 <shieldQueueEntryCompare>--Type <RET> for more, q to quit, c to continue without paging--
0x0000556e0edd0bcc <+76>: call 0x556e0ed74d40 <QuickSort>
0x0000556e0edd0bd1 <+81>: cmpq $0x0,0x28(%rbx)
0x0000556e0edd0bd6 <+86>: je 0x556e0edd0cb8 <shieldFlushEntries+312>
0x0000556e0edd0bdc <+92>: xor %ebp,%ebp
0x0000556e0edd0bde <+94>: xor %r12d,%r12d
0x0000556e0edd0be1 <+97>: xor %r14d,%r14d
0x0000556e0edd0be4 <+100>: xor %r13d,%r13d
0x0000556e0edd0be7 <+103>: jmp 0x556e0edd0c34 <shieldFlushEntries+180>
0x0000556e0edd0be9 <+105>: nopl 0x0(%rax)
0x0000556e0edd0bf0 <+112>: test %r13,%r13
0x0000556e0edd0bf3 <+115>: je 0x556e0edd0c91 <shieldFlushEntries+273>
0x0000556e0edd0bf9 <+121>: cmp %r14,%r13
0x0000556e0edd0bfc <+124>: jae 0x556e0edd0d00 <shieldFlushEntries+384>
0x0000556e0edd0c02 <+130>: mov %r12d,%edx
0x0000556e0edd0c05 <+133>: mov %r14,%rsi
0x0000556e0edd0c08 <+136>: mov %r13,%rdi
0x0000556e0edd0c0b <+139>: call 0x556e0edcf8b0 <ProtSet>
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 <shieldFlushEntries+288>
--Type <RET> for more, q to quit, c to continue without paging--
0x0000556e0edd0c34 <+180>: mov %rbp,%rsi
0x0000556e0edd0c37 <+183>: mov %rbx,%rdi
0x0000556e0edd0c3a <+186>: call 0x556e0ed806d0 <shieldDequeue>
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 <shieldFlushEntries+170>
0x0000556e0edd0c5b <+219>: movzbl %dl,%edx
0x0000556e0edd0c5e <+222>: mov %r15,%rsi
0x0000556e0edd0c61 <+225>: mov %rbx,%rdi
0x0000556e0edd0c64 <+228>: call 0x556e0ed6ed50 <shieldSetPM>
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 <shieldFlushEntries+112>
0x0000556e0edd0c7e <+254>: mov 0x10(%r15),%rdx
0x0000556e0edd0c82 <+258>: cmp 0x10(%rdx),%r14
0x0000556e0edd0c86 <+262>: je 0x556e0edd0c26 <shieldFlushEntries+166>
0x0000556e0edd0c88 <+264>: test %r13,%r13
0x0000556e0edd0c8b <+267>: jne 0x556e0edd0bf9 <shieldFlushEntries+121>
0x0000556e0edd0c91 <+273>: mov %eax,%r12d
--Type <RET> for more, q to quit, c to continue without paging--
0x0000556e0edd0c94 <+276>: jmp 0x556e0edd0c1e <shieldFlushEntries+158>
0x0000556e0edd0c96 <+278>: cs nopw 0x0(%rax,%rax,1)
0x0000556e0edd0ca0 <+288>: test %r13,%r13
0x0000556e0edd0ca3 <+291>: je 0x556e0edd0cb8 <shieldFlushEntries+312>
0x0000556e0edd0ca5 <+293>: cmp %r14,%r13
0x0000556e0edd0ca8 <+296>: jae 0x556e0edd0d1e <shieldFlushEntries+414>
0x0000556e0edd0caa <+298>: mov %r12d,%edx
0x0000556e0edd0cad <+301>: mov %r14,%rsi
0x0000556e0edd0cb0 <+304>: mov %r13,%rdi
0x0000556e0edd0cb3 <+307>: call 0x556e0edcf8b0 <ProtSet>
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 <shieldQueueReset>
0x0000556e0edd0cce <+334>: xchg %ax,%ax
0x0000556e0edd0cd0 <+336>: add $0x8,%rsp
0x0000556e0edd0cd4 <+340>: lea 0x3c4e3(%rip),%rdx # 0x556e0ee0d1be
0x0000556e0edd0cdb <+347>: mov $0x190,%esi
0x0000556e0edd0ce0 <+352>: pop %rbx
0x0000556e0edd0ce1 <+353>: lea 0x3a269(%rip),%rdi # 0x556e0ee0af51
0x0000556e0edd0ce8 <+360>: pop %rbp
0x0000556e0edd0ce9 <+361>: pop %r12
--Type <RET> 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) # 0x556e0ee8c870 <mps_lib_assert_handler>
0x0000556e0edd0cf7 <+375>: nopw 0x0(%rax,%rax,1)
0x0000556e0edd0d00 <+384>: lea 0x3a97c(%rip),%rdx # 0x556e0ee0b683
0x0000556e0edd0d07 <+391>: mov $0x1a0,%esi
0x0000556e0edd0d0c <+396>: lea 0x3a23e(%rip),%rdi # 0x556e0ee0af51
0x0000556e0edd0d13 <+403>: call *0xbbb57(%rip) # 0x556e0ee8c870 <mps_lib_assert_handler>
0x0000556e0edd0d19 <+409>: jmp 0x556e0edd0c02 <shieldFlushEntries+130>
0x0000556e0edd0d1e <+414>: lea 0x3a95e(%rip),%rdx # 0x556e0ee0b683
0x0000556e0edd0d25 <+421>: mov $0x1aa,%esi
0x0000556e0edd0d2a <+426>: lea 0x3a220(%rip),%rdi # 0x556e0ee0af51
0x0000556e0edd0d31 <+433>: call *0xbbb39(%rip) # 0x556e0ee8c870 <mps_lib_assert_handler>
0x0000556e0edd0d37 <+439>: jmp 0x556e0edd0caa <shieldFlushEntries+298>
End of assembler dump.
>> #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output
>> (p=<optimized out>, 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)
>
> 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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 15:13:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 15:37:02 GMT) Full text and rfc822 format available.Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: Óscar Fuentes <bug-gnu-emacs <at> gnu.org>, 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 15:36:09 +0000
Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> Óscar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> 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=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0)
> at ./nptl/pthread_kill.c:44
> tid = <optimized out>
> ret = 0
> pd = <optimized out>
> old_mask = {__val = {0}}
> ret = <optimized out>
> #1 0x00007f487751de2f in __pthread_kill_internal (threadid=<optimized out>, signo=6)
> at ./nptl/pthread_kill.c:78
> #2 0x00007f48774c9d02 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/posix/raise.c:26
> ret = <optimized out>
> #3 0x0000556e0ead9d68 in terminate_due_to_signal
> (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ../../emacs/src/emacs.c:463
> #4 0x0000556e0ed16d73 in set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1023
> old_state = <optimized out>
> old_state = <optimized out>
> #5 set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1002
> old_state = <optimized out>
> #6 igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>)
> 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):
ENOMEM
Changing the protection of a memory region would result in
the total number of mappings with distinct attributes (e.g.,
read versus read/write protection) exceeding the allowed
maximum. (For example, making the protection of a range
PROT_READ in the middle of a region currently protected as
PROT_READ|PROT_WRITE would result in three mappings: two
read/write mappings at each end and a read-only mapping in
the 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=<optimized out>, args=<optimized out>) at ../../emacs/src/json.c:1812
> count = {bytes = <optimized out>}
> conf = {object_type = <optimized out>, array_type = <optimized out>, null_object = <optimized out>, false_object = <optimized out>}
> p = {input_current = 0x556e3342596e "}],\"detail\":\"struct\",\"kind\":23,\"name\":\"ra_struct_0xAB71CCE7u<true>\",\"range\":{\"end\":{\"character\":62,\"line\":9091},\"start\":{\"character\":0,\"line\":9091}},\"selectionRange\":{\"end\":{\"character\":10,\"line\":9091"..., input_begin = 0x556e32ee1f60 "{\"id\":17456,\"jsonrpc\":\"2.0\",\"result\":[{\"children\":[{\"detail\":\"lp0::PluginInfoAdder\",\"kind\":13,\"name\":\"ppa8\",\"range\":{\"end\":{\"character\":33,\"line\":7},\"start\":{\"character\":0,\"line\":7}},\"selectionRange\":"..., input_end = 0x556e33733f5e "", secondary_input_begin = 0x0, secondary_input_end = 0x0, current_line = 1, current_column = 5519886, point_of_current_line = 0, available_depth = 9993, conf = {object_type = json_object_hashtable, array_type = json_array_array, null_object = 0x0, false_object = 0x0}, additional_bytes_count = 0, internal_object_workspace = {0x7f4767c48874, 0x110c2, 0x7f4767c4889c, 0x7f4767c488c4, 0x7f4767c4972d, 0x7f4767c4c63d, 0x7f4767c4cd4d, 0x7f4767c4f9c5, 0x7f4767c53005, 0x7f4767c53ef5, 0x7f4767c54df5, 0x7f4767c55ce5, 0x7f4767c58bf5, 0x7f4767c59ae5, 0x7f4767c5c76d, 0x7f4767c5dd9d, 0x7f4767c60c8d, 0x7f4767c61b7d, 0x7f4767c62a6d, 0x7f4767c6395d, 0x7f4767c6689d, 0x7f4767c6778d, 0x7f4767c6868d, 0x7f4767c6957d, 0x7f4767c6c48d, 0x7f4767c6d37d, 0x7f4767c6e26d, 0x7f4767c6f15d, 0x7f4767c7009d, 0x7f4767c70f8d, 0x7f4767c71e7d, 0x7f4767c74d7d, 0x7f4767c75c6d, 0x7f4767c76b7d, 0x7f4767c77a6d, 0x7f4767c7a9ad, 0x7f4767c7b89d, 0x7f4767c7c78d, 0x7f4767c7d67d, 0x7f4767c80575, 0x7f4767c81465, 0x7f4767c8237d, 0x7f4767c8326d, 0x7f4767c8615d, 0x7f4767c8704d, 0x7f4767c87f3d, 0x7f4767c88e5d, 0x7f4767c89d4d, 0x7f4767c8cc8d, 0x7f4767c8cd64, 0x7f4767c8d4dd, 0x7f4767c--Type <RET> for more, q to quit, c to continue without paging--
> 8d4f4, 0x7f4767c8d51c, 0x7f4767c8d544, 0x56, 0x7f4767c8d56c, 0x7f4767c8d594, 0x7f4767c8d5bc, 0x7f4767c8d805, 0x7f4767c8d8c4, 0x7f4767c8d93d, 0x7f4767c8d9fc, 0x2, 0x21e}, object_workspace = 0x556e374c43e0, object_workspace_size = 4096, object_workspace_current = 4023, internal_byte_workspace = "9091acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177\000\000\000\000\000\000\000\000\000\000\020\370\302\016nU\000\000\b\000\000\000\000\000\000\000\020\321\025;\375\177\000\000\t\000\000\000\000\000\000\000\310\321\025;\375\177\000\000\000\000\000\000\000\000\000\000\020\370\302\016nU\000\000\b\000\000\000\000\000\000\000p\321\025;\375\177\000\000"..., byte_workspace = 0x7ffd3b15d050 "9091acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\375\177", byte_workspace_end = 0x7ffd3b15d250 "P\320\025;\375\177", byte_workspace_current = 0x7ffd3b15d054 "acterRange(lxw_chart_options::x_scale) *, const lxw_chart_options *))*))s *)bj *)mats))ement *)mat *)...).).)\321\025;\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 <shieldFlushEntries+180>
> 0x0000556e0edd0be9 <+105>: nopl 0x0(%rax)
> 0x0000556e0edd0bf0 <+112>: test %r13,%r13
> 0x0000556e0edd0bf3 <+115>: je 0x556e0edd0c91 <shieldFlushEntries+273>
> 0x0000556e0edd0bf9 <+121>: cmp %r14,%r13
> 0x0000556e0edd0bfc <+124>: jae 0x556e0edd0d00 <shieldFlushEntries+384>
> 0x0000556e0edd0c02 <+130>: mov %r12d,%edx
> 0x0000556e0edd0c05 <+133>: mov %r14,%rsi
> 0x0000556e0edd0c08 <+136>: mov %r13,%rdi
> 0x0000556e0edd0c0b <+139>: call 0x556e0edcf8b0 <ProtSet>
> => 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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 15:37:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 15:51:01 GMT) Full text and rfc822 format available.Message #26 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 16:49:54 +0100
Pip Cet <pipcet <at> protonmail.com> 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 <ProtSet+168>
0x0000556e0edcf8c6 <+22>: test %rbp,%rbp
0x0000556e0edcf8c9 <+25>: je 0x556e0edcf980 <ProtSet+208>
0x0000556e0edcf8cf <+31>: sub %rbp,%rbx
0x0000556e0edcf8d2 <+34>: cmp $0x7fffffff,%rbx
0x0000556e0edcf8d9 <+41>: ja 0x556e0edcf9b0 <ProtSet+256>
0x0000556e0edcf8df <+47>: mov $0x5,%edx
0x0000556e0edcf8e4 <+52>: cmp $0x2,%r12d
0x0000556e0edcf8e8 <+56>: je 0x556e0edcf8f6 <ProtSet+70>
0x0000556e0edcf8ea <+58>: ja 0x556e0edcf930 <ProtSet+128>
0x0000556e0edcf8ec <+60>: mov $0x7,%edx
0x0000556e0edcf8f1 <+65>: test %r12d,%r12d
0x0000556e0edcf8f4 <+68>: jne 0x556e0edcf94f <ProtSet+159>
0x0000556e0edcf8f6 <+70>: mov %rbx,%rsi
0x0000556e0edcf8f9 <+73>: mov %rbp,%rdi
0x0000556e0edcf8fc <+76>: call 0x556e0ead23b0 <mprotect <at> plt>
0x0000556e0edcf901 <+81>: test %eax,%eax
0x0000556e0edcf903 <+83>: je 0x556e0edcf928 <ProtSet+120>
0x0000556e0edcf905 <+85>: pop %rbx
--Type <RET> 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 <mps_lib_assert_handler>
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 <ProtSet+159>
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 <mps_lib_assert_handler>
0x0000556e0edcf94f <+159>: xor %edx,%edx
0x0000556e0edcf951 <+161>: jmp 0x556e0edcf8f6 <ProtSet+70>
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 <mps_lib_assert_handler>
0x0000556e0edcf971 <+193>: test %rbp,%rbp
0x0000556e0edcf974 <+196>: jne 0x556e0edcf8cf <ProtSet+31>
--Type <RET> 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 <mps_lib_assert_handler>
0x0000556e0edcf99c <+236>: cmp $0x7fffffff,%rbx
0x0000556e0edcf9a3 <+243>: jbe 0x556e0edcf8df <ProtSet+47>
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 <mps_lib_assert_handler>
0x0000556e0edcf9c9 <+281>: jmp 0x556e0edcf8df <ProtSet+47>
End of assembler dump.
HTH
_________________________________________________________________
________________________________________________________
Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 16:12:01 GMT) Full text and rfc822 format available.Message #29 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 16:11:03 +0000
Óscar Fuentes <oscarfv <at> eclipso.eu> writes: > Pip Cet <pipcet <at> protonmail.com> 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 = 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 <ProtSet+168> > 0x0000556e0edcf8c6 <+22>: test %rbp,%rbp > 0x0000556e0edcf8c9 <+25>: je 0x556e0edcf980 <ProtSet+208> > 0x0000556e0edcf8cf <+31>: sub %rbp,%rbx > 0x0000556e0edcf8d2 <+34>: cmp $0x7fffffff,%rbx > 0x0000556e0edcf8d9 <+41>: ja 0x556e0edcf9b0 <ProtSet+256> > 0x0000556e0edcf8df <+47>: mov $0x5,%edx > 0x0000556e0edcf8e4 <+52>: cmp $0x2,%r12d > 0x0000556e0edcf8e8 <+56>: je 0x556e0edcf8f6 <ProtSet+70> > 0x0000556e0edcf8ea <+58>: ja 0x556e0edcf930 <ProtSet+128> > 0x0000556e0edcf8ec <+60>: mov $0x7,%edx > 0x0000556e0edcf8f1 <+65>: test %r12d,%r12d > 0x0000556e0edcf8f4 <+68>: jne 0x556e0edcf94f <ProtSet+159> > 0x0000556e0edcf8f6 <+70>: mov %rbx,%rsi > 0x0000556e0edcf8f9 <+73>: mov %rbp,%rdi > 0x0000556e0edcf8fc <+76>: call 0x556e0ead23b0 <mprotect <at> plt> > 0x0000556e0edcf901 <+81>: test %eax,%eax > 0x0000556e0edcf903 <+83>: je 0x556e0edcf928 <ProtSet+120> This calls mprotect, and we only reach it when the return value is nonzero. > 0x0000556e0edcf905 <+85>: pop %rbx > --Type <RET> 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 <mps_lib_assert_handler> 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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 16:22:02 GMT) Full text and rfc822 format available.Message #32 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: oscarfv <at> eclipso.eu, 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 18:21:14 +0200
> Cc: 76705 <at> 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" <bug-gnu-emacs <at> gnu.org> > > > #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?)
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 16:51:01 GMT) Full text and rfc822 format available.Message #35 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 17:50:15 +0100
Pip Cet <pipcet <at> protonmail.com> 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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Mon, 03 Mar 2025 19:58:02 GMT) Full text and rfc822 format available.Message #38 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Mon, 03 Mar 2025 19:57:27 +0000
Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
> Pip Cet <pipcet <at> protonmail.com> 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 = 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
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 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.
No reason to apologize, I'm not even sure it's a problem. just something
I noticed in the assembly listing.
Pip
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Tue, 04 Mar 2025 19:05:02 GMT) Full text and rfc822 format available.Message #41 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Tue, 04 Mar 2025 19:04:34 +0000
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/<emacs PID>/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 <pipcet <at> protonmail.com> writes:
> Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
>
>> Pip Cet <pipcet <at> protonmail.com> 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 garbage 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 reached and an Emacs crash:
```
/* .assume.mprotect.base */
result = mprotect((void *)base, (size_t)AddrOffset(base, limit), flags);
if (MAYBE_HARDENED_RUNTIME && result != 0 && errno == 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
* <design/prot#impl.xc.prot.exec> for details. */
prot_all = PROT_READ | PROT_WRITE;
result = mprotect((void *)base, (size_t)AddrOffset(base, limit), flags & prot_all);
}
if (result != 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 keeps 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 page in a large contiguous map is `mprotect`ed to be different than its neighbors, that map turns into three maps for the purposes of the max_map_count limit, and `mprotect` eventually returns `ENOMEM`.
Experiments with lowering the `max_map_count` limit in a virtual machine appear to be consistent with that theory, because it causes Emacs crashes much like the ones that were reported by our users.
Pip
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Wed, 05 Mar 2025 03:55:02 GMT) Full text and rfc822 format available.Message #44 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76705 <at> debbugs.gnu.org, Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, Helmut Eller <eller.helmut <at> gmail.com> Subject: Re: bug#76705: 31.0.50; igc: crash Date: Wed, 05 Mar 2025 04:54:03 +0100
Pip Cet <pipcet <at> protonmail.com> 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!
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Wed, 05 Mar 2025 12:35:01 GMT) Full text and rfc822 format available.Message #47 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Helmut Eller <eller.helmut <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Wed, 05 Mar 2025 13:34:47 +0100
[Message part 1 (text/plain, inline)]
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
[mprot.c (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Wed, 05 Mar 2025 13:47:01 GMT) Full text and rfc822 format available.Message #50 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Helmut Eller <eller.helmut <at> gmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, 76705 <at> debbugs.gnu.org Subject: Re: bug#76705: 31.0.50; igc: crash Date: Wed, 05 Mar 2025 13:45:59 +0000
"Helmut Eller" <eller.helmut <at> gmail.com> 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)
> (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.
3.23user 4.00system 0:07.56elapsed 95%CPU (0avgtext+0avgdata 3723392maxresident)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
bug-gnu-emacs <at> gnu.org:bug#76705; Package emacs.
(Thu, 06 Mar 2025 07:53:02 GMT) Full text and rfc822 format available.Message #53 received at 76705 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Helmut Eller <eller.helmut <at> gmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Pip Cet <pipcet <at> protonmail.com>, 76705 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#76705: 31.0.50; igc: crash Date: Thu, 06 Mar 2025 08:52:10 +0100
Helmut Eller <eller.helmut <at> gmail.com> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.