GNU bug report logs - #79854
crash in emacs master branch: Segmentation fault.ld_to_fill()

Previous Next

To reply to this bug, email your comments to 79854 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: bug-gnu-emacs <at> gnu.org
Subject: crash in emacs master branch: Segmentation fault.ld_to_fill()
Date: Mon, 17 Nov 2025 22:26:18 +0200

Salve dear gurus!

Emacs of
  c9372ced9c0 (HEAD -> master, origin/master, origin/HEAD) : Update ldefs-boot.el.
is built with
 $ ./configure --with-x-toolkit=lucid --enable-checking=yes,glyphs --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0' LDFLAGS=-ggdb3 'CXXFLAGS=-ggdb3 -O0' --no-create

run under gdb to freeze with

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.ld_to_fill(),                         |is displayed.  Here is sample code:
                                                          *va0x00005555558b4259 in SYMBOL_NAME (sym=...) at lisp.h:2364w-code-setup ()
/usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259                       |    ;; use `ffip-diff-mode' from package find-file-in-project instead of `diff-mode'

when approximately at time I attempted to copy-paste a piece of text
from the system clipboard (X11/xfce4 window manager).

The gdb session is alive and can be queried by your requests.

Cheers,

Andrei


(gdb) bt
+bt   
#0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
#1  0x00005555558bc7e9 in print_object (obj=XIL(0x55559406b720), printcharfun=XIL(0x30), escapeflag=true) at print.c:2460
#2  0x00005555558b901e in print (obj=XIL(0x55559406b720), printcharfun=XIL(0x30), escapeflag=true) at print.c:1323
#3  0x00005555558b7c0f in Fprin1 (object=XIL(0x55559406b720), printcharfun=XIL(0x30), overrides=XIL(0)) at print.c:786
#4  0x00005555558b8a40 in print_error_message (data=XIL(0x5555936f6543), stream=XIL(0x30), context=0x7ffff030fb25 "", caller=XIL(0xdbf0)) at print.c:1162
#5  0x000055555578f45c in Fcommand_error_default_function (data=XIL(0x5555936f6543), context=XIL(0x7fffef9ec9b4), signal=XIL(0xdbf0)) at keyboard.c:1100
#6  0x0000555555880551 in funcall_subr (subr=0x555555ab3fa0 <Scommand_error_default_function>, numargs=3, args=0x7fffeedff050) at eval.c:3249
#7  0x00005555558e3541 in exec_byte_code (fun=XIL(0x7ffff005f1ed), args_template=771, nargs=3, args=0x7fffffffd8d0) at bytecode.c:822
#8  0x0000555555880c15 in funcall_lambda (fun=XIL(0x7ffff005f1ed), nargs=3, arg_vector=0x7fffffffd8b8) at eval.c:3336
#9  0x000055555587fe8f in funcall_general (fun=XIL(0x7ffff005f1ed), numargs=3, args=0x7fffffffd8b8) at eval.c:3128
#10 0x0000555555880154 in Ffuncall (nargs=4, args=0x7fffffffd8b0) at eval.c:3177
#11 0x000055555578f1b3 in cmd_error_internal (data=XIL(0x5555936f6543), context=0x7fffffffd940 "") at keyboard.c:1042
#12 0x000055555578f05e in cmd_error (data=XIL(0x5555936f6543)) at keyboard.c:1010
#13 0x000055555587bebf in internal_condition_case (bfun=0x55555578fa4a <command_loop_1>, handlers=XIL(0x90), hfun=0x55555578ee3d <cmd_error>) at eval.c:1686
#14 0x000055555578f5ed in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1163
#15 0x000055555587b298 in internal_catch (tag=XIL(0x12750), func=0x55555578f5bf <command_loop_2>, arg=XIL(0x90)) at eval.c:1370
#16 0x000055555578f57b in command_loop () at keyboard.c:1141
#17 0x000055555578e8bf in recursive_edit_1 () at keyboard.c:749
#18 0x000055555578eaf3 in Frecursive_edit () at keyboard.c:832
#19 0x0000555555789ef5 in main (argc=7, argv=0x7fffffffdd58) at emacs.c:2629


(gdb) xbacktrace
+xbacktrace
++set $bt = backtrace_top ()
++while backtrace_p ($bt)
+++set $fun = backtrace_function ($bt)
+++xgettype $fun
++++if (CHECK_LISP_OBJECT_TYPE)
+++++set $bugfix = $fun.i
++++set $type = (enum Lisp_Type) (USE_LSB_TAG ? (EMACS_INT) $bugfix & (1 << GCTYPEBITS) - 1 : (EMACS_UINT) $bugfix >> VALBITS)
+++if $type == Lisp_Symbol
++++xprintsym $fun
+++++xsymname $fun
++++++xgetsym $fun
+++++++xgetptr $fun
++++++++if (CHECK_LISP_OBJECT_TYPE)
+++++++++set $bugfix = $fun.i
++++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
+++++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
++++++set $symname = $ptr->u.s.name
+++++xgetptr $symname
++++++if (CHECK_LISP_OBJECT_TYPE)
+++++++set $bugfix = $symname.i
++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
+++++if $ptr != 0
++++++set $sym_name = (struct Lisp_String *) $ptr
++++++xprintstr $sym_name
+++++++if (! $arg0)
++++++++set $data = (char *) $sym_name->u.s.data
++++++++set $strsize = ($sym_name->u.s.size_byte < 0) ? ($sym_name->u.s.size & ~ARRAY_MARK_FLAG) : $sym_name->u.s.size_byte
++++++++if $strsize == 0
+++++++++output ($sym_name->u.s.size > 1000) ? 0 : ($data[0])@($strsize)
"command-error-default-function"++++printf " (0x%x)\n", backtrace_args ($bt)
 (0xeedff050)
+++set $bt = backtrace_next ($bt)
+++set $fun = backtrace_function ($bt)
+++xgettype $fun
++++if (CHECK_LISP_OBJECT_TYPE)
+++++set $bugfix = $fun.i
++++set $type = (enum Lisp_Type) (USE_LSB_TAG ? (EMACS_INT) $bugfix & (1 << GCTYPEBITS) - 1 : (EMACS_UINT) $bugfix >> VALBITS)
+++if $type == Lisp_Symbol
++++xprintsym $fun
+++++xsymname $fun
++++++xgetsym $fun
+++++++xgetptr $fun
++++++++if (CHECK_LISP_OBJECT_TYPE)
+++++++++set $bugfix = $fun.i
++++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
+++++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
++++++set $symname = $ptr->u.s.name
+++++xgetptr $symname
++++++if (CHECK_LISP_OBJECT_TYPE)
+++++++set $bugfix = $symname.i
++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
+++++if $ptr != 0
++++++set $sym_name = (struct Lisp_String *) $ptr
++++++xprintstr $sym_name
+++++++if (! $arg0)
++++++++set $data = (char *) $sym_name->u.s.data
++++++++set $strsize = ($sym_name->u.s.size_byte < 0) ? ($sym_name->u.s.size & ~ARRAY_MARK_FLAG) : $sym_name->u.s.size_byte
++++++++if $strsize == 0
+++++++++output ($sym_name->u.s.size > 1000) ? 0 : ($data[0])@($strsize)
"help-command-error-confusable-suggestions"++++printf " (0x%x)\n", backtrace_args ($bt)
 (0xffffd8b8)
+++set $bt = backtrace_next ($bt)

Message #8 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 15:18:03 +0200

> Date: Mon, 17 Nov 2025 22:26:18 +0200
> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Salve dear gurus!
> 
> Emacs of
>   c9372ced9c0 (HEAD -> master, origin/master, origin/HEAD) : Update ldefs-boot.el.
> is built with
>  $ ./configure --with-x-toolkit=lucid --enable-checking=yes,glyphs --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0' LDFLAGS=-ggdb3 'CXXFLAGS=-ggdb3 -O0' --no-create
> 
> run under gdb to freeze with
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.ld_to_fill(),                         |is displayed.  Here is sample code:
>                                                           *va0x00005555558b4259 in SYMBOL_NAME (sym=...) at lisp.h:2364w-code-setup ()
> /usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259                       |    ;; use `ffip-diff-mode' from package find-file-in-project instead of `diff-mode'
> 
> when approximately at time I attempted to copy-paste a piece of text
> from the system clipboard (X11/xfce4 window manager).

What was the piece of text, and which application produced it?

Also, your report lacks the data about the Emacs build and the
underlying OS, which "M-x report-emacs-bug" collects.  That could be
relevant, so please post it.

> The gdb session is alive and can be queried by your requests.
> 
> Cheers,
> 
> Andrei
> 
> 
> (gdb) bt
> +bt   
> #0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
> #1  0x00005555558bc7e9 in print_object (obj=XIL(0x55559406b720), printcharfun=XIL(0x30), escapeflag=true) at print.c:2460

First things first:

  (gdb) frame 0
  (gdb) print sym
  (gdb) xtype

If the last command says it's a Lisp symbol, then follow with

  (gdb) xsymbol

Message #11 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 16:26:19 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Mon, 17 Nov 2025 22:26:18 +0200
>> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Salve dear gurus!
>> 
>> Emacs of
>>   c9372ced9c0 (HEAD -> master, origin/master, origin/HEAD) : Update ldefs-boot.el.
>> is built with
>>  $ ./configure --with-x-toolkit=lucid --enable-checking=yes,glyphs --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0' LDFLAGS=-ggdb3 'CXXFLAGS=-ggdb3 -O0' --no-create
>> 
>> run under gdb to freeze with
>> 
>> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.ld_to_fill(),                         |is displayed.  Here is sample code:
>>                                                           *va0x00005555558b4259 in SYMBOL_NAME (sym=...) at lisp.h:2364w-code-setup ()
>> /usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259                       |    ;; use `ffip-diff-mode' from package find-file-in-project instead of `diff-mode'
>> 
>> when approximately at time I attempted to copy-paste a piece of text
>> from the system clipboard (X11/xfce4 window manager).
>
> What was the piece of text, and which application produced it?

Emacs was run under gdb which itself in a screen session.
 "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
 (I could not grep that symbol in the emacs sources).

>
> Also, your report lacks the data about the Emacs build and the
> underlying OS, which "M-x report-emacs-bug" collects.  That could be
> relevant, so please post it.

Done now:

---------------------------------------------------------------------
In GNU Emacs 31.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw3d scroll bars) of 2025-11-15 built on
 andrei-MS-7D96
Repository revision: c9372ced9c03eac6dfaa2dedbb4033ce0a253499
Repository branch: master
System Description: Ubuntu 24.04.3 LTS

Configured using:
 'configure --with-x-toolkit=lucid --enable-checking=yes,glyphs
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0' LDFLAGS=-ggdb3
 'CXXFLAGS=-ggdb3 -O0''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINERAMA XINPUT2
XPM XRANDR LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  desktop-save-mode: t
  winner-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-history-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-nonselected-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt grep oc-basic org-element
org-persist org-id org-refile org-element-ast avl-tree generator ol-eww
eww vtable url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
pixel-fill kinsoku url-file svg gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
parse-time gnus-spec gnus-int gnus-range message sendmail rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader
gnus-util mail-utils range mm-util mail-prsvr ol-docview doc-view
jka-compr image-mode exif ol-bibtex bibtex iso8601 ol-bbdb ol-w3m ol-doi
org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-src ob-comint org-pcomplete org-list org-footnote org-faces
org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol
org-fold org-fold-core org-keys oc org-loaddefs cal-menu calendar
cal-loaddefs org-version org-compat org-macs yank-media hi-lock
perl-mode edebug debug backtrace sh-script smie executable log-view
lsp-inline-completion follow bug-reference hideshow lsp-lens
lsp-diagnostics lsp-modeline lsp-headerline lsp-icons lsp-zig lsp-yang
lsp-yaml lsp-xml lsp-wgsl lsp-volar lsp-vimscript lsp-vhdl lsp-vetur
lsp-html lsp-verilog lsp-vala lsp-v lsp-typos lsp-typespec lsp-typeprof
lsp-ttcn3 lsp-ts-query lsp-trunk lsp-toml-tombi lsp-toml lsp-tilt
lsp-tex lsp-terraform lsp-svelte lsp-steep lsp-sqls lsp-sql lsp-sorbet
lsp-solidity lsp-solargraph lsp-semgrep lsp-rust lsp-ruff
lsp-ruby-syntax-tree lsp-ruby-lsp lsp-rubocop lsp-roslyn lsp-roc lsp-rf
lsp-remark lsp-racket lsp-r lsp-qml lsp-python-ty lsp-pylsp lsp-pyls
lsp-pwsh lsp-purescript lsp-postgres lsp-pls lsp-php lsp-perlnavigator
lsp-perl lsp-openscad lsp-odin lsp-ocaml find-file lsp-nushell lsp-nix
lsp-nim lsp-nginx lsp-nextflow lsp-move lsp-mojo lsp-mint lsp-meson
lsp-mdx lsp-matlab lsp-marksman lsp-markdown lsp-magik lsp-fennel
lsp-lua lsp-lisp lsp-kubernetes-helm lsp-kotlin lsp-json lsp-jq
lsp-javascript lsp-idris lsp-haxe lsp-hack lsp-groovy lsp-graphql
lsp-golangci-lint lsp-glsl lsp-gleam lsp-gdscript lsp-fsharp lsp-futhark
lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elm lsp-elixir
lsp-earthly lsp-dockerfile lsp-dhall lsp-d lsp-cypher lsp-cucumber
lsp-copilot lsp-css lsp-c3 lsp-csharp gnutls lsp-crystal lsp-credo
lsp-cobol lsp-cmake lsp-clojure lsp-clangd dom lsp-bufls lsp-go
lsp-completion lsp-beancount lsp-bash lsp-awk lsp-autotools lsp-astro
lsp-asm lsp-ansible lsp-angular lsp-ada lsp-semantic-tokens
lsp-actionscript vc-git files-x vc-dispatcher tabify cl-print help-fns
radix-tree misearch multi-isearch apropos selected-window-contrast
desktop treesit-fold treesit-fold-summary treesit-fold-parsers
treesit-fold-util mule-util lsp-ui lsp-ui-doc goto-addr lsp-ui-imenu
lsp-ui-peek lsp-ui-sideline lsp-ui-util face-remap find-func frameset
winner cus-edit cus-start cus-load 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 epa derived magit-repos
magit-apply magit-wip magit-log which-func magit-diff smerge-mode diff
diff-mode track-changes easy-mmode git-commit log-edit pcvs-util add-log
magit-core magit-margin magit-transient c++-ts-mode c-ts-mode
c-ts-common treesit gud advice lsp lsp-mode lsp-protocol xref project
tree-widget wid-edit spinner network-stream puny nsm markdown-mode color
noutline outline lv inline imenu ht f s ewoc epg rfc6068 epg-config dash
compile text-property-search sql view thingatpt cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
use-package-core finder-inf blamer-autoloads async-autoloads
git-link-autoloads git-timemachine-autoloads lsp-ui-autoloads
lsp-mode-autoloads ht-autoloads f-autoloads dash-autoloads lv-autoloads
magit-autorevert autorevert filenotify magit-process with-editor shell
pcomplete comint ansi-osc ring server ansi-color magit-mode transient pp
edmacro kmacro benchmark magit-git magit-base magit-section format-spec
cursor-sensor crm llama comp comp-cstr cond-let compat magit-autoloads
pcase magit-section-autoloads llama-autoloads cond-let-autoloads
markdown-mode-autoloads posframe-autoloads s-autoloads
selected-window-accent-mode-autoloads selected-window-contrast-autoloads
spinner-autoloads treesit-fold-autoloads vc-msg-autoloads
popup-autoloads info with-editor-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 password-cache json map
url-vars cl-extra help-mode warnings icons dired-aux dired
dired-loaddefs comp-run comp-common rx time-date subr-x cl-loaddefs
cl-lib term/screen term/xterm xterm byte-opt gv bytecomp byte-compile
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 dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 2986593 313547) (symbols 48 65056 0)
 (strings 32 368692 30495) (string-bytes 1 11023448)
 (vectors 16 177443) (vector-slots 8 2901328 207635)
 (floats 8 9980 155681) (intervals 56 219937 1278) (buffers 1064 1777))
------------------------------------------------------------------------
>
>> The gdb session is alive and can be queried by your requests.
>> 
>> Cheers,
>> 
>> Andrei
>> 
>> 
>> (gdb) bt
>> +bt   
>> #0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
>> #1 0x00005555558bc7e9 in print_object (obj=XIL(0x55559406b720),
>> printcharfun=XIL(0x30), escapeflag=true) at print.c:2460
>
> First things first:
>
>   (gdb) frame 0
>   (gdb) print sym
>   (gdb) xtype
>

+f 0
#0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
/usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
(gdb) print sym
+print sym
$2 = XIL(0x55559406b720)
(gdb) xtype
+xtype
++xgettype $
+++if (CHECK_LISP_OBJECT_TYPE)
++++set $bugfix = $.i
+++set $type = (enum Lisp_Type) (USE_LSB_TAG ? (EMACS_INT) $bugfix & (1 << GCTYPEBITS) - 1 : (EMACS_UINT) $bugfix >> VALBITS)
++output $type
Lisp_Symbol++echo \n

++if $type == Lisp_Vectorlike


> If the last command says it's a Lisp symbol, then follow with
>
>   (gdb) xsymbol


(gdb) xsymbol 
+xsymbol 
++set $sym = $
++xgetsym $sym
+++xgetptr $sym
++++if (CHECK_LISP_OBJECT_TYPE)
+++++set $bugfix = $sym.i
++++set $ptr = (EMACS_INT) $bugfix & VALMASK
+++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
++print (struct Lisp_Symbol *) $ptr
$3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
++xprintsym $sym
+++xsymname $sym
++++xgetsym $sym
+++++xgetptr $sym
++++++if (CHECK_LISP_OBJECT_TYPE)
+++++++set $bugfix = $sym.i
++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
+++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
++++set $symname = $ptr->u.s.name
Cannot access memory at address 0xaaaae9bb11e8
(gdb) 

Message #14 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 17:00:28 +0200

> From: andrei.elkin <at> pp.inet.fi
> Cc: 79854 <at> debbugs.gnu.org
> Date: Tue, 18 Nov 2025 16:26:19 +0200
> 
> >> when approximately at time I attempted to copy-paste a piece of text
> >> from the system clipboard (X11/xfce4 window manager).
> >
> > What was the piece of text, and which application produced it?
> 
> Emacs was run under gdb which itself in a screen session.
>  "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
>  (I could not grep that symbol in the emacs sources).

No, I mean which application put the text into the clipboard?

> (gdb) xsymbol 
> +xsymbol 
> ++set $sym = $
> ++xgetsym $sym
> +++xgetptr $sym
> ++++if (CHECK_LISP_OBJECT_TYPE)
> +++++set $bugfix = $sym.i
> ++++set $ptr = (EMACS_INT) $bugfix & VALMASK
> +++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
> ++print (struct Lisp_Symbol *) $ptr
> $3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
> ++xprintsym $sym
> +++xsymname $sym
> ++++xgetsym $sym
> +++++xgetptr $sym
> ++++++if (CHECK_LISP_OBJECT_TYPE)
> +++++++set $bugfix = $sym.i
> ++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
> +++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
> ++++set $symname = $ptr->u.s.name
> Cannot access memory at address 0xaaaae9bb11e8

Sorry, I have no idea how that happens.  In general, Emacs tried to
report some error, but that's all I see from the backtrace.

Message #17 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 17:13:54 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: andrei.elkin <at> pp.inet.fi
>> Cc: 79854 <at> debbugs.gnu.org
>> Date: Tue, 18 Nov 2025 16:26:19 +0200
>> 
>> >> when approximately at time I attempted to copy-paste a piece of text
>> >> from the system clipboard (X11/xfce4 window manager).
>> >
>> > What was the piece of text, and which application produced it?
>> 
>> Emacs was run under gdb which itself in a screen session.
>>  "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
>>  (I could not grep that symbol in the emacs sources).
>
> No, I mean which application put the text into the clipboard?

I am not sure what it was, my bad.. (as I did expect something bad to
re-occure at one pointt). Probably it was from an emacs frame that I
mouse-selected. Besides I had gnome-terminals and firefox.

The crashed emacs instance is accessed via ssh from another box + emacsclient.

>
>> (gdb) xsymbol 
>> +xsymbol 
>> ++set $sym = $
>> ++xgetsym $sym
>> +++xgetptr $sym
>> ++++if (CHECK_LISP_OBJECT_TYPE)
>> +++++set $bugfix = $sym.i
>> ++++set $ptr = (EMACS_INT) $bugfix & VALMASK
>> +++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>> ++print (struct Lisp_Symbol *) $ptr
>> $3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
>> ++xprintsym $sym
>> +++xsymname $sym
>> ++++xgetsym $sym
>> +++++xgetptr $sym
>> ++++++if (CHECK_LISP_OBJECT_TYPE)
>> +++++++set $bugfix = $sym.i
>> ++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
>> +++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>> ++++set $symname = $ptr->u.s.name
>> Cannot access memory at address 0xaaaae9bb11e8
>
> Sorry, I have no idea how that happens.  In general, Emacs tried to
> report some error, but that's all I see from the backtrace.

It might come back I believe (given my rather routine use of Emacs).
Anything you might suggest to catch something essential in future?

Message #20 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 17:26:17 +0200

> From: andrei.elkin <at> pp.inet.fi
> Cc: 79854 <at> debbugs.gnu.org
> Date: Tue, 18 Nov 2025 17:13:54 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: andrei.elkin <at> pp.inet.fi
> >> Cc: 79854 <at> debbugs.gnu.org
> >> Date: Tue, 18 Nov 2025 16:26:19 +0200
> >> 
> >> >> when approximately at time I attempted to copy-paste a piece of text
> >> >> from the system clipboard (X11/xfce4 window manager).
> >> >
> >> > What was the piece of text, and which application produced it?
> >> 
> >> Emacs was run under gdb which itself in a screen session.
> >>  "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
> >>  (I could not grep that symbol in the emacs sources).
> >
> > No, I mean which application put the text into the clipboard?
> 
> I am not sure what it was, my bad.. (as I did expect something bad to
> re-occure at one pointt). Probably it was from an emacs frame that I
> mouse-selected. Besides I had gnome-terminals and firefox.
> 
> The crashed emacs instance is accessed via ssh from another box + emacsclient.
> 
> >
> >> (gdb) xsymbol 
> >> +xsymbol 
> >> ++set $sym = $
> >> ++xgetsym $sym
> >> +++xgetptr $sym
> >> ++++if (CHECK_LISP_OBJECT_TYPE)
> >> +++++set $bugfix = $sym.i
> >> ++++set $ptr = (EMACS_INT) $bugfix & VALMASK
> >> +++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
> >> ++print (struct Lisp_Symbol *) $ptr
> >> $3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
> >> ++xprintsym $sym
> >> +++xsymname $sym
> >> ++++xgetsym $sym
> >> +++++xgetptr $sym
> >> ++++++if (CHECK_LISP_OBJECT_TYPE)
> >> +++++++set $bugfix = $sym.i
> >> ++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
> >> +++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
> >> ++++set $symname = $ptr->u.s.name
> >> Cannot access memory at address 0xaaaae9bb11e8
> >
> > Sorry, I have no idea how that happens.  In general, Emacs tried to
> > report some error, but that's all I see from the backtrace.
> 
> It might come back I believe (given my rather routine use of Emacs).
> Anything you might suggest to catch something essential in future?

It would be good to understand what caused Emacs to signal an error in
the first place.

Message #23 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 17:45:39 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: andrei.elkin <at> pp.inet.fi
>> Cc: 79854 <at> debbugs.gnu.org
>> Date: Tue, 18 Nov 2025 17:13:54 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: andrei.elkin <at> pp.inet.fi
>> >> Cc: 79854 <at> debbugs.gnu.org
>> >> Date: Tue, 18 Nov 2025 16:26:19 +0200
>> >> 
>> >> >> when approximately at time I attempted to copy-paste a piece of text
>> >> >> from the system clipboard (X11/xfce4 window manager).
>> >> >
>> >> > What was the piece of text, and which application produced it?
>> >> 
>> >> Emacs was run under gdb which itself in a screen session.
>> >>  "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
>> >>  (I could not grep that symbol in the emacs sources).
>> >
>> > No, I mean which application put the text into the clipboard?
>> 
>> I am not sure what it was, my bad.. (as I did expect something bad to
>> re-occure at one pointt). Probably it was from an emacs frame that I
>> mouse-selected. Besides I had gnome-terminals and firefox.
>> 
>> The crashed emacs instance is accessed via ssh from another box + emacsclient.
>> 
>> >
>> >> (gdb) xsymbol 
>> >> +xsymbol 
>> >> ++set $sym = $
>> >> ++xgetsym $sym
>> >> +++xgetptr $sym
>> >> ++++if (CHECK_LISP_OBJECT_TYPE)
>> >> +++++set $bugfix = $sym.i
>> >> ++++set $ptr = (EMACS_INT) $bugfix & VALMASK
>> >> +++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>> >> ++print (struct Lisp_Symbol *) $ptr
>> >> $3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
>> >> ++xprintsym $sym
>> >> +++xsymname $sym
>> >> ++++xgetsym $sym
>> >> +++++xgetptr $sym
>> >> ++++++if (CHECK_LISP_OBJECT_TYPE)
>> >> +++++++set $bugfix = $sym.i
>> >> ++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
>> >> +++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>> >> ++++set $symname = $ptr->u.s.name
>> >> Cannot access memory at address 0xaaaae9bb11e8
>> >
>> > Sorry, I have no idea how that happens.  In general, Emacs tried to
>> > report some error, but that's all I see from the backtrace.
>> 
>> It might come back I believe (given my rather routine use of Emacs).
>> Anything you might suggest to catch something essential in future?
>
> It would be good to understand what caused Emacs to signal an error in
> the first place.

I might join this hunting journey, but obviously would have to climb a
lot. Let me ask about the very top of the stack

0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
/usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
(gdb) p sym
+p sym
$4 = XIL(0x55559406b720)
(gdb) pr sym
+pr sym
++pp $
+++set $tmp = $
+++set $output_debug = print_output_debug_flag
+++set print_output_debug_flag = 0
+++call safe_debug_print ($tmp)
#<INVALID_LISP_OBJECT 0x55559406b720>
+++set print_output_debug_flag = $output_debug

The segfault apparently (and I may be wrong of course) deals with
INVALID_LISP_OBJECT. Is it possible to track where the object gets such
status?

Message #26 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 17:56:03 +0200

> From: andrei.elkin <at> pp.inet.fi
> Cc: 79854 <at> debbugs.gnu.org
> Date: Tue, 18 Nov 2025 17:45:39 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: andrei.elkin <at> pp.inet.fi
> >> Cc: 79854 <at> debbugs.gnu.org
> >> Date: Tue, 18 Nov 2025 17:13:54 +0200
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> From: andrei.elkin <at> pp.inet.fi
> >> >> Cc: 79854 <at> debbugs.gnu.org
> >> >> Date: Tue, 18 Nov 2025 16:26:19 +0200
> >> >> 
> >> >> >> when approximately at time I attempted to copy-paste a piece of text
> >> >> >> from the system clipboard (X11/xfce4 window manager).
> >> >> >
> >> >> > What was the piece of text, and which application produced it?
> >> >> 
> >> >> Emacs was run under gdb which itself in a screen session.
> >> >>  "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
> >> >>  (I could not grep that symbol in the emacs sources).
> >> >
> >> > No, I mean which application put the text into the clipboard?
> >> 
> >> I am not sure what it was, my bad.. (as I did expect something bad to
> >> re-occure at one pointt). Probably it was from an emacs frame that I
> >> mouse-selected. Besides I had gnome-terminals and firefox.
> >> 
> >> The crashed emacs instance is accessed via ssh from another box + emacsclient.
> >> 
> >> >
> >> >> (gdb) xsymbol 
> >> >> +xsymbol 
> >> >> ++set $sym = $
> >> >> ++xgetsym $sym
> >> >> +++xgetptr $sym
> >> >> ++++if (CHECK_LISP_OBJECT_TYPE)
> >> >> +++++set $bugfix = $sym.i
> >> >> ++++set $ptr = (EMACS_INT) $bugfix & VALMASK
> >> >> +++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
> >> >> ++print (struct Lisp_Symbol *) $ptr
> >> >> $3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
> >> >> ++xprintsym $sym
> >> >> +++xsymname $sym
> >> >> ++++xgetsym $sym
> >> >> +++++xgetptr $sym
> >> >> ++++++if (CHECK_LISP_OBJECT_TYPE)
> >> >> +++++++set $bugfix = $sym.i
> >> >> ++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
> >> >> +++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
> >> >> ++++set $symname = $ptr->u.s.name
> >> >> Cannot access memory at address 0xaaaae9bb11e8
> >> >
> >> > Sorry, I have no idea how that happens.  In general, Emacs tried to
> >> > report some error, but that's all I see from the backtrace.
> >> 
> >> It might come back I believe (given my rather routine use of Emacs).
> >> Anything you might suggest to catch something essential in future?
> >
> > It would be good to understand what caused Emacs to signal an error in
> > the first place.
> 
> I might join this hunting journey, but obviously would have to climb a
> lot. Let me ask about the very top of the stack
> 
> 0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
> /usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
> (gdb) p sym
> +p sym
> $4 = XIL(0x55559406b720)
> (gdb) pr sym
> +pr sym
> ++pp $
> +++set $tmp = $
> +++set $output_debug = print_output_debug_flag
> +++set print_output_debug_flag = 0
> +++call safe_debug_print ($tmp)
> #<INVALID_LISP_OBJECT 0x55559406b720>
> +++set print_output_debug_flag = $output_debug
> 
> The segfault apparently (and I may be wrong of course) deals with
> INVALID_LISP_OBJECT. Is it possible to track where the object gets such
> status?

If we figure out which code and why signaled this error, we could then
see what was the symbol originally, and then how it got corrupted.

Message #29 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79854 <at> debbugs.gnu.org, andrei.elkin <at> pp.inet.fi
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Tue, 18 Nov 2025 21:39:31 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> From: andrei.elkin <at> pp.inet.fi
>> Cc: 79854 <at> debbugs.gnu.org
>> Date: Tue, 18 Nov 2025 17:45:39 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: andrei.elkin <at> pp.inet.fi
>> >> Cc: 79854 <at> debbugs.gnu.org
>> >> Date: Tue, 18 Nov 2025 17:13:54 +0200
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> >> From: andrei.elkin <at> pp.inet.fi
>> >> >> Cc: 79854 <at> debbugs.gnu.org
>> >> >> Date: Tue, 18 Nov 2025 16:26:19 +0200
>> >> >>
>> >> >> >> when approximately at time I attempted to copy-paste a piece of text
>> >> >> >> from the system clipboard (X11/xfce4 window manager).
>> >> >> >
>> >> >> > What was the piece of text, and which application produced it?
>> >> >>
>> >> >> Emacs was run under gdb which itself in a screen session.
>> >> >>  "...Segmentation fault.ld_to_fill()" is probably from outside of emacs
>> >> >>  (I could not grep that symbol in the emacs sources).
>> >> >
>> >> > No, I mean which application put the text into the clipboard?
>> >>
>> >> I am not sure what it was, my bad.. (as I did expect something bad to
>> >> re-occure at one pointt). Probably it was from an emacs frame that I
>> >> mouse-selected. Besides I had gnome-terminals and firefox.
>> >>
>> >> The crashed emacs instance is accessed via ssh from another box + emacsclient.
>> >>
>> >> >
>> >> >> (gdb) xsymbol
>> >> >> +xsymbol
>> >> >> ++set $sym = $
>> >> >> ++xgetsym $sym
>> >> >> +++xgetptr $sym
>> >> >> ++++if (CHECK_LISP_OBJECT_TYPE)
>> >> >> +++++set $bugfix = $sym.i
>> >> >> ++++set $ptr = (EMACS_INT) $bugfix & VALMASK
>> >> >> +++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>> >> >> ++print (struct Lisp_Symbol *) $ptr
>> >> >> $3 = (struct Lisp_Symbol *) 0xaaaae9bb11e0
>> >> >> ++xprintsym $sym
>> >> >> +++xsymname $sym
>> >> >> ++++xgetsym $sym
>> >> >> +++++xgetptr $sym
>> >> >> ++++++if (CHECK_LISP_OBJECT_TYPE)
>> >> >> +++++++set $bugfix = $sym.i
>> >> >> ++++++set $ptr = (EMACS_INT) $bugfix & VALMASK
>> >> >> +++++set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>> >> >> ++++set $symname = $ptr->u.s.name
>> >> >> Cannot access memory at address 0xaaaae9bb11e8
>> >> >
>> >> > Sorry, I have no idea how that happens.  In general, Emacs tried to
>> >> > report some error, but that's all I see from the backtrace.
>> >>
>> >> It might come back I believe (given my rather routine use of Emacs).
>> >> Anything you might suggest to catch something essential in future?
>> >
>> > It would be good to understand what caused Emacs to signal an error in
>> > the first place.
>>
>> I might join this hunting journey, but obviously would have to climb a
>> lot. Let me ask about the very top of the stack
>>
>> 0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
>> /usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
>> (gdb) p sym
>> +p sym
>> $4 = XIL(0x55559406b720)
>> (gdb) pr sym
>> +pr sym
>> ++pp $
>> +++set $tmp = $
>> +++set $output_debug = print_output_debug_flag
>> +++set print_output_debug_flag = 0
>> +++call safe_debug_print ($tmp)
>> #<INVALID_LISP_OBJECT 0x55559406b720>
>> +++set print_output_debug_flag = $output_debug
>>
>> The segfault apparently (and I may be wrong of course) deals with
>> INVALID_LISP_OBJECT. Is it possible to track where the object gets such
>> status?
>
> If we figure out which code and why signaled this error, we could then
> see what was the symbol originally, and then how it got corrupted.

I doubt it was a symbol originally. It looks like a normal pointer that
was written into a Lisp_Object slot somewhere, where it was
misinterpreted as a symbol because it's eight-byte aligned.

We should inspect the memory that it actually points to when interpreted
as an ordinary pointer.

Can you try x/64gx 0x55559406b700?

Thanks!

Pip

Message #32 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 79854 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Wed, 19 Nov 2025 12:05:04 +0200

Howdy Pip!

>>> 0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
>>> /usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
>>> (gdb) p sym
>>> +p sym
>>> $4 = XIL(0x55559406b720)
>>> (gdb) pr sym
>>> +pr sym
>>> ++pp $
>>> +++set $tmp = $
>>> +++set $output_debug = print_output_debug_flag
>>> +++set print_output_debug_flag = 0
>>> +++call safe_debug_print ($tmp)
>>> #<INVALID_LISP_OBJECT 0x55559406b720>
>>> +++set print_output_debug_flag = $output_debug
>>>
>>> The segfault apparently (and I may be wrong of course) deals with
>>> INVALID_LISP_OBJECT. Is it possible to track where the object gets such
>>> status?
>>
>> If we figure out which code and why signaled this error, we could then
>> see what was the symbol originally, and then how it got corrupted.
>
> I doubt it was a symbol originally. It looks like a normal pointer that
> was written into a Lisp_Object slot somewhere, where it was
> misinterpreted as a symbol because it's eight-byte aligned.
>
> We should inspect the memory that it actually points to when interpreted
> as an ordinary pointer.
>
> Can you try x/64gx 0x55559406b700?

(gdb) x/64gx 0x55559406b700

+x/64gx 0x55559406b700
0x55559406b700: 0x0000000000000004      0x000055559406b6f0
0x55559406b710: 0x0000000000000004      0x000055559406b700
0x55559406b720: 0x0000000000000004      0x000055559406b710
0x55559406b730: 0x0000000000000004      0x000055559406b720
0x55559406b740: 0x0000000000000004      0x000055559406b730
0x55559406b750: 0x0000000000000004      0x000055559406b740
0x55559406b760: 0x0000000000000004      0x000055559406b750
0x55559406b770: 0x0000000000000004      0x000055559406b760
0x55559406b780: 0x0000000000000004      0x000055559406b770
0x55559406b790: 0x0000000000000004      0x000055559406b780
0x55559406b7a0: 0x0000000000000004      0x000055559406b790
0x55559406b7b0: 0x0000000000000004      0x000055559406b7a0
0x55559406b7c0: 0x0000000000000004      0x000055559406b7b0
0x55559406b7d0: 0x0000000000000004      0x000055559406b7c0
0x55559406b7e0: 0x0000000000000004      0x000055559406b7d0
0x55559406b7f0: 0x0000000000000004      0x000055559406b7e0
0x55559406b800: 0x0000000000000004      0x000055559406b7f0
0x55559406b810: 0x0000000000000004      0x000055559406b800
0x55559406b820: 0x0000000000000004      0x000055559406b810
0x55559406b830: 0x0000000000000004      0x000055559406b820
0x55559406b840: 0x0000000000000004      0x000055559406b830
0x55559406b850: 0x0000000000000004      0x000055559406b840
0x55559406b860: 0x0000000000000004      0x000055559406b850
0x55559406b870: 0x0000000000000004      0x000055559406b860
0x55559406b880: 0x0000000000000004      0x000055559406b870
0x55559406b890: 0x0000000000000004      0x000055559406b880
0x55559406b8a0: 0x0000000000000004      0x000055559406b890
0x55559406b8b0: 0x0000000000000004      0x000055559406b8a0
0x55559406b8c0: 0x0000000000000004      0x000055559406b8b0
0x55559406b8d0: 0x0000000000000004      0x000055559406b8c0
0x55559406b8e0: 0x0000000000000004      0x000055559406b8d0
0x55559406b8f0: 0x0000000000000004      0x000055559406b8e0


>
> Thanks!
>
> Pip

Thank yo as well, I am all ears for further inspection commands.


/ndrei

Message #35 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Wed, 19 Nov 2025 14:30:37 +0000

<andrei.elkin <at> pp.inet.fi> writes:

> Howdy Pip!
>
>>>> 0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
>>>> /usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
>>>> (gdb) p sym
>>>> +p sym
>>>> $4 = XIL(0x55559406b720)
>>>> (gdb) pr sym
>>>> +pr sym
>>>> ++pp $
>>>> +++set $tmp = $
>>>> +++set $output_debug = print_output_debug_flag
>>>> +++set print_output_debug_flag = 0
>>>> +++call safe_debug_print ($tmp)
>>>> #<INVALID_LISP_OBJECT 0x55559406b720>
>>>> +++set print_output_debug_flag = $output_debug
>>>>
>>>> The segfault apparently (and I may be wrong of course) deals with
>>>> INVALID_LISP_OBJECT. Is it possible to track where the object gets such
>>>> status?
>>>
>>> If we figure out which code and why signaled this error, we could then
>>> see what was the symbol originally, and then how it got corrupted.
>>
>> I doubt it was a symbol originally. It looks like a normal pointer that
>> was written into a Lisp_Object slot somewhere, where it was
>> misinterpreted as a symbol because it's eight-byte aligned.
>>
>> We should inspect the memory that it actually points to when interpreted
>> as an ordinary pointer.
>>
>> Can you try x/64gx 0x55559406b700?
>
> (gdb) x/64gx 0x55559406b700
>
> +x/64gx 0x55559406b700
> 0x55559406b700: 0x0000000000000004      0x000055559406b6f0
> 0x55559406b710: 0x0000000000000004      0x000055559406b700

That looks like a bunch of freed conses. It seems we're seeing a
use-after-free error here.

Your initial report involved the symbol 0xdbf0. We need to find out what
that is in your build: please run

    p 0xdbf0 / sizeof (struct Lisp_Symbol)

(the response is very likely to be 1173)

then look into the src/globals.h file for the line

    #define iQ<something> 1173

The <something> part is the name of the symbol we're looking for.

If it's module_out_of_memory (which is nearby in my build), that might
give us a hint where to look further. Are you using any modules, by any
chance?

Thanks!

Pip

Message #38 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 79854 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Wed, 19 Nov 2025 18:42:39 +0200

>>>
>>> Can you try x/64gx 0x55559406b700?
>>
>> (gdb) x/64gx 0x55559406b700
>>
>> +x/64gx 0x55559406b700
>> 0x55559406b700: 0x0000000000000004      0x000055559406b6f0
>> 0x55559406b710: 0x0000000000000004      0x000055559406b700
>
> That looks like a bunch of freed conses. It seems we're seeing a
> use-after-free error here.
>
> Your initial report involved the symbol 0xdbf0. We need to find out what
> that is in your build: please run
>
>     p 0xdbf0 / sizeof (struct Lisp_Symbol)
>
> (the response is very likely to be 1173)
>
> then look into the src/globals.h file for the line
>
>     #define iQ<something> 1173
>
> The <something> part is the name of the symbol we're looking for.

#define iQmouse_fixup_help_message 1173
DEFINE_LISP_SYMBOL (Qmouse_fixup_help_message)

This finding fits to the mouse activity that were involved!
You are certainly on the right track :prayer:.

>
> If it's module_out_of_memory (which is nearby in my build), that might
> give us a hint where to look further. Are you using any modules, by any
> chance?

No modules.

>
> Thanks!
>
> Pip

Message #41 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org, pipcet <at> protonmail.com
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Wed, 19 Nov 2025 19:03:26 +0200

> From: andrei.elkin <at> pp.inet.fi
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  79854 <at> debbugs.gnu.org
> Date: Wed, 19 Nov 2025 18:42:39 +0200
> 
> > Your initial report involved the symbol 0xdbf0. We need to find out what
> > that is in your build: please run
> >
> >     p 0xdbf0 / sizeof (struct Lisp_Symbol)
> >
> > (the response is very likely to be 1173)
> >
> > then look into the src/globals.h file for the line
> >
> >     #define iQ<something> 1173
> >
> > The <something> part is the name of the symbol we're looking for.
> 
> #define iQmouse_fixup_help_message 1173
> DEFINE_LISP_SYMBOL (Qmouse_fixup_help_message)

But does

  (gdb) p 0xdbf0 / sizeof (struct Lisp_Symbol)

indeed display 1173 in your case?  We need to be sure that we are not
chasing a wild goose here.

Message #44 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: andrei.elkin <at> pp.inet.fi
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79854 <at> debbugs.gnu.org, pipcet <at> protonmail.com
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Wed, 19 Nov 2025 20:32:30 +0200

Eli,

>> From: andrei.elkin <at> pp.inet.fi
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  79854 <at> debbugs.gnu.org
>> Date: Wed, 19 Nov 2025 18:42:39 +0200
>> 
>> > Your initial report involved the symbol 0xdbf0. We need to find out what
>> > that is in your build: please run
>> >
>> >     p 0xdbf0 / sizeof (struct Lisp_Symbol)
>> >
>> > (the response is very likely to be 1173)
>> >
>> > then look into the src/globals.h file for the line
>> >
>> >     #define iQ<something> 1173
>> >
>> > The <something> part is the name of the symbol we're looking for.
>> 
>> #define iQmouse_fixup_help_message 1173
>> DEFINE_LISP_SYMBOL (Qmouse_fixup_help_message)
>
> But does
>
>   (gdb) p 0xdbf0 / sizeof (struct Lisp_Symbol)
>
> indeed display 1173 in your case?  We need to be sure that we are not
> chasing a wild goose here.

#0  0x00005555558b4259 in SYMBOL_NAME (sym=XIL(0x55559406b720)) at lisp.h:2364
/usr/local/src/emacs/git/WTs/master/src/lisp.h:2364:74044:beg:0x5555558b4259
(gdb)  p 0xdbf0 / sizeof (struct Lisp_Symbol)
+p 0xdbf0 / sizeof (struct Lisp_Symbol)
$7 = 1173

Message #47 received at 79854 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: andrei.elkin <at> pp.inet.fi
Cc: 79854 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79854: crash in emacs master branch: Segmentation
 fault.ld_to_fill()
Date: Wed, 19 Nov 2025 19:59:38 +0000

<andrei.elkin <at> pp.inet.fi> writes:

>>>>
>>>> Can you try x/64gx 0x55559406b700?
>>>
>>> (gdb) x/64gx 0x55559406b700
>>>
>>> +x/64gx 0x55559406b700
>>> 0x55559406b700: 0x0000000000000004      0x000055559406b6f0
>>> 0x55559406b710: 0x0000000000000004      0x000055559406b700
>>
>> That looks like a bunch of freed conses. It seems we're seeing a
>> use-after-free error here.
>>
>> Your initial report involved the symbol 0xdbf0. We need to find out what
>> that is in your build: please run
>>
>>     p 0xdbf0 / sizeof (struct Lisp_Symbol)
>>
>> (the response is very likely to be 1173)
>>
>> then look into the src/globals.h file for the line
>>
>>     #define iQ<something> 1173
>>
>> The <something> part is the name of the symbol we're looking for.
>
> #define iQmouse_fixup_help_message 1173
> DEFINE_LISP_SYMBOL (Qmouse_fixup_help_message)
>
> This finding fits to the mouse activity that were involved!

Yes; IIUC, the X selection code is very tricky because "large"
selections are handled differently from small ones. Just to see whether
we're on the right track here, please do:

p selection_request_stack
p *selection_request_stack
p outstanding_transfers
p outstanding_transfers.next
p property_change_reply
p reading_selection_reply
p *XCONS(0x5555936f543)
p *XCONS(XCDR(0x5555936f543))
p *XCONS(XCDR(XCDR(0x5555936f543)))
pp XCAR(0x5555936f543)
pp XCAR(XCDR(0x5555936f543))
pp XCAR(XCDR(XCDR(0x5555936f543)))

The last ones might give us a clue if it's not the xselect code after
all...

> You are certainly on the right track :prayer:.

Let's see what the above produces.

Thanks again!

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.