Can you describe what you were doing at the time of the crash?

I was not doing anything in particular (editing a latex file with LaTeX/PS mode). These crashes have happened to me at very random times. The only thing that I have been suspecting could be causing this is viewing org-mode buffers that have special fontification. I have https://github.com/awth13/org-appear and https://github.com/minad/org-modern installed, and previously I had https://github.com/integral-dw/org-superstar-mode. I had just viewed an org file before the crash.

Please show the details of 'v'.  Like this:

  (gdb) frame 0
  (gdb) p v
  (gdb) p/x v->header

Also, you've elided the part where GDB says what fatal signal was
delivered.  I'm guessing it was SIGSEGV, but please show that part of
what GDB displayed when it kicked in.

Please keep the crashed session inside GDB in case we want you to look
around and report more data.

Unfortunately, I don't have the program running (because I foolishly thought I could continue from the crash). I do have the core however, here is what you both asked for:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  vector_marked_p (v=v@entry=0x4000000023000008) at alloc.c:4273

warning: 4273   alloc.c: No such file or directory
[Current thread is 1 (LWP 691035)]
warning: File "/nix/store/ji2c308n46lfvpi9jpr3ma8rqq42wx3p-glib-2.82.4/lib/libgobject-2.0.so.0.8200.4-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/nix/store/ji2c308n46lfvpi9jpr3ma8rqq42wx3p-glib-2.82.4/lib/libglib-2.0.so.0.8200.4-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/nix/store/8ryr50ic059w32djkygs1g1kxdpj7dgx-isl-0.20/lib/libisl.so.19.1.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/nix/store/fjyh571wr8ifsw1h6j2nx22fmjj91b6y-gcc-14-20241116-lib/lib/libstdc++.so.6.0.33-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
(gdb) frame 0
#0  vector_marked_p (v=v@entry=0x4000000023000008) at alloc.c:4273
4273    in alloc.c
(gdb) p v
$1 = (const struct Lisp_Vector *) 0x4000000023000008
(gdb) p/x v->header
Cannot access memory at address 0x4000000023000008
(gdb) set print elements 0
(gdb) p last_marked
$2 = {0x15554ea7b163, 0x1f3eb0, 0x15554ea7b153, 0x15554ea7b113, 0x10710, 0x15554ea7b103, 0xe344f4, 0x2237643, 0x10da0, 0x2237633, 0x15554de36280, 0xc64485 <Sselected_window+5>, 0x15554de5d268, 0x13ff3ad, 0x2, 0x1d373234, 0x46ddbcd, 0x15554de5d450, 0x15554df5c948, 0x60, 0x0, 0x15554ec524dd, 0x15554eb23723, 0x0, 0x15554eb24c65, 0x0, 0x0, 0xa, 0x10710, 0x15554df5c8b8, 0x60, 0x0, 0x0, 0x0, 0x3e10, 0x15554e014d50, 0x60, 0x0,
  0x15554ed0a8e5, 0x15554eb2b183, 0x0, 0x15554eb73b0d, 0x0, 0x0, 0x16, 0x7842613, 0x1d54f9e4, 0x31d4a, 0x9839b1d, 0x1818f8b3, 0x9540, 0x1818f873, 0x1818f893, 0x3d80, 0x1818f883, 0x30, 0x1818f853, 0x30, 0x0, 0x1ce4e9ad, 0x1be0b704, 0x18505ee3, 0x18505f03, 0xdc20, 0xa, 0x18505eb3, 0x18505ec3, 0xdb90, 0x2, 0x18505e43, 0x18505e93, 0x96c0, 0x18505e83, 0x3a, 0x18505e73, 0xa, 0x18505e53, 0x6, 0x4d533dd, 0x20ccaced, 0x1818fc43,
  0x9540, 0x1818fc33, 0x0, 0x1818fc13, 0xe460, 0x0, 0x1ce4e9ad, 0x0, 0x0, 0x30, 0x20ccad45, 0x179dfc73, 0x9540, 0x179dfc63, 0x0, 0x179dfc03, 0x179dfc53, 0x15554de617c0, 0x179dfc13, 0x1bb24600, 0x60, 0x18502db3, 0x95a0, 0x18502dc3, 0x18502f33, 0x0, 0x18502f43, 0x466b42d, 0x406, 0x1d49ebc4, 0x46cfcd5, 0x15554e0bd5c8 <F756e6971756966792d726174696f6e616c697a65_uniquify_rationalize_0+744>, 0x60, 0x1475f63, 0x95a0, 0x1475f53,
  0x2242473, 0x248c664, 0x2242433, 0x1475f03, 0x4290, 0x1475ef3, 0x103f8b4, 0x1475ee3, 0x103f8d4, 0x1475ed3, 0x0, 0x1475ec3, 0x0, 0x1475f43, 0x0, 0x1475f33, 0x15554edb315b, 0x4290, 0x15554edb316b, 0x15554eb8d5fc, 0x15554edb317b, 0x15554edb318c, 0x15554eb2c6b3, 0x24b5b4d, 0x0, 0x0, 0x245d955, 0x0, 0x0, 0x15554e0bd578 <F756e6971756966792d726174696f6e616c697a65_uniquify_rationalize_0+664>, 0x60, 0x2242523, 0x15554de31ee0,
  0x2242513, 0x24b5c25, 0x15554de31ee0, 0x15554e0bd578 <F756e6971756966792d726174696f6e616c697a65_uniquify_rationalize_0+664>, 0x2242b13, 0x2242ad3, 0x2242753, 0x15554dfd07e8, 0x127db30, 0x2242b23, 0x15554ece9985, 0x15554de35860, 0x15554dff3f28, 0x15554ece9985, 0x15554ece9abb, 0x10140, 0x15554ece9acb, 0x30, 0x0, 0x192, 0x15554ece9a15, 0x606, 0x15554ece9a6c, 0x15554ece9a45, 0x15554de35288, 0x15554ece9a5b, 0x15554dfd0818,
  0x16, 0x15554eb2b3a4, 0x15554ece99b5, 0x606, 0x15554ece99f4, 0x15554ece99e5, 0x7b60, 0x12, 0x15554eb2b2d4, 0x2242ac3, 0x15554eb2b275, 0x22429d3, 0x2242993, 0x2, 0x222be93, 0x15554f00ebbd, 0x2242983, 0x15554eb2b275, 0x2220813, 0x251724d, 0x15554de323b8, 0x22207c3, 0x1ee26a3, 0x15554e3190c8 <top_level_run+728>, 0x1ee26b3, 0xa49d00 <pure+3488800>, 0x60, 0x226e9d3, 0x15554de5a568, 0x226e9c3, 0x1f73c54, 0x226ea63,
  0x15554de5ec50, 0x226ea53, 0x226ea83, 0x1eea8c3, 0x15554e26ab80 <F7363726f6c6c2d6261722d746f6f6c6b69742d7363726f6c6c_scroll_bar_toolkit_scroll_0+1136>, 0x60, 0x42c7a73, 0x13e60, 0x42c7a63, 0x42c7a53, 0x15554def15c8, 0x42c7a43, 0xc197c0 <pure+5388000>, 0x42c7a33, 0x36df2c0, 0x60, 0x0, 0x43f78f5, 0x42caeb3, 0x0, 0x4384d5d, 0x0, 0x0, 0x42c7a93, 0x15554dea8fb0, 0x42c7a83, 0x43d4c94, 0x0, 0x1eea8d3, 0x15554de48168,
  0x1eea8e3, 0x1f73cf4, 0x1eea8f3, 0x1f73d14, 0x226ea73, 0x1eea873, 0x1253d0, 0x1eea883, 0x15554de48168, 0x1eea893, 0x1f73cb4, 0x1eea8a3, 0x1f73cd4, 0x226ea43, 0x1eea7f3, 0x1253d0, 0x1eea813, 0x15554de48168, 0x1eea823, 0x1f73c74, 0x1eea833, 0x1f73c94, 0x226eba3, 0x15554de30d68, 0x226eb93, 0x226eb83, 0x226eb73, 0xb0eba0 <pure+4295360>, 0x15554dfc0740, 0x60, 0x1f652493, 0x15554de32c08, 0x1f6524a3, 0x124f290, 0x60, 0x0,
  0x538cb05, 0x1f67b0c3, 0x9540, 0x1f67b093, 0x1f67b0b3, 0x30, 0x1f67b0a3, 0x30, 0x1f67b083, 0x30, 0x0, 0x1baba95d, 0x20bef7e4, 0x1f67e3e3, 0x1f67e3f3, 0xdc20, 0xa, 0x1f67e3c3, 0x1f67e3d3, 0xdb90, 0x2, 0x1f67e1d3, 0x1f67e3b3, 0x96c0, 0x1f67e3a3, 0x3a, 0x1f67e393, 0xa, 0x1f67e1e3, 0x6, 0x979f79d, 0x9492115, 0x1f67b4f3, 0x9540, 0x1f67b353, 0x1f67b393, 0x30, 0x1f67b383, 0x30, 0x1f67b373, 0x3d80, 0x1f67b363, 0x30,
  0x1f67b343, 0x30, 0x0, 0x1baba95d, 0x0, 0x0, 0x30, 0x949216d, 0x1f67b323, 0x9540, 0x1f67b2e3, 0x1f67b313, 0x30, 0x1f67b303, 0x30, 0x1f67b2f3, 0x30, 0x1f67b2d3, 0x30, 0x0, 0x1baba95d, 0x0, 0x0, 0x30, 0x94921c5, 0x1f67b163, 0x9540, 0x1f67b153, 0x0, 0x1f67b0f3, 0xe460, 0x0, 0x1baba95d, 0x0, 0x0, 0x30, 0x949221d, 0x1f67b2b3, 0x9540, 0x1f67b2a3, 0x0, 0x1f67b263, 0x1f67b293, 0xafe0, 0x1f67b283, 0xa2, 0x1f67b273, 0xa2, 0x0,
  0x1baba95d, 0x0, 0x0, 0x30, 0x9492275, 0x1f67b243, 0x9540, 0x1f67b233, 0x0, 0x1f67b203, 0x1f67b223, 0x15554de617c0, 0x1f67b213, 0x15554df1a3a0, 0x60, 0x1f641ba3, 0x95a0, 0x1f641bb3, 0x1f641bc3, 0x8ae5574, 0x1f641bd3, 0x15554ec0ff33, 0x4290, 0x15554ec0ff43, 0x15554ec0ff84, 0x15554ec0ff53, 0x15554ec0ff64, 0x15554eb2c6b3, 0x38294cd, 0x1f6463e3, 0x9540, 0x1f6463a3, 0x1f6463d3, 0x30, 0x1f6463c3, 0x3d50, 0x1f6463b3, 0x30,
  0x1f646393, 0x30, 0x0, 0x98e7985, 0x8f680f4, 0x1f647ac3, 0x1f647ad3, 0xdc20, 0xa, 0x1f647aa3, 0x1f647ab3, 0xdb90, 0x2, 0x1f647a53, 0x1f647a93, 0x96c0, 0x1f647a83, 0x3a, 0x1f647a73, 0xa, 0x1f647a63, 0x6, 0x98e79dd, 0x98f1d0d, 0x0, 0x400000002300000d, 0x0, 0x27f62ad, 0x0, 0x0, 0x60, 0x2235443, 0x10da0, 0x2235433, 0x30, 0xc6d2a5 <Sactive_minibuffer_window+5>, 0x15554defbf98, 0x60, 0x15554ea7b0c3, 0x15554de5dc98,
  0x15554ea7b0b3, 0xe33ed5, 0x606, 0xe34c84, 0xe33eb5, 0x15554de78758, 0x15554defbf98, 0xe33e85, 0x606, 0xe35054, 0xe33e6d, 0x10710, 0x60, 0x15554f053c7b, 0x7da0, 0x15554f053c8b, 0x11850, 0x60, 0x15554f4abdeb, 0x7da0, 0x15554f4abdfb, 0x11850, 0x15554f4abe0b, 0x7e00, 0x15554f4abe1b, 0x15554f4abeab, 0x11850, 0x15554f4abe2b, 0x7dd0, 0x15554f4abe3b, 0x15554f4abe8b, 0x11850, 0x15554f4abe9b, 0x2, 0x15554f4abe4b, 0xd530,
  0x15554f4abe5b, 0x15554f4abe6b, 0x15554f4abe7b, 0x2, 0x11850, 0x0, 0x15554f053c9b, 0x7e00, 0x15554f053cab, 0x15554f053d3b, 0x10710, 0x15554f053cbb, 0x7dd0, 0x15554f053ccb, 0x15554f053d1b, 0x10710, 0x15554f053d2b, 0x2, 0x15554f053cdb, 0xd530, 0x15554f053ceb, 0x15554f053cfb, 0x15554f053d0b, 0x2, 0x10710, 0xc643c5 <Sselect_window+5>, 0x3de0, 0x1a, 0xe35074, 0x1e, 0xe35094}
(gdb) p last_marked_index
$3 = 431



This part seems to indicate you run something called
gcmh-idle-garbage-collect, which triggers GC from a timer function?
If so, please describe what you do with this and show the relevant
code.

In general, please describe anything related to GC and timers that you
customized in your sessions, as that could be relevant to the nature
and the reasons of this bug.


Yes, I am using gcmh (https://github.com/emacsmirror/gcmh/blob/master/gcmh.el). I have these parameters for it:

(setq gcmh-idle-delay 'auto  ; default is 15s
      gcmh-auto-idle-delay-factor 10
      gcmh-high-cons-threshold (* 64 1024 1024))  ; 64mb


I don't think that there is anything else GC related that I am using.

Also, what is the memory footprint of the crashed Emacs process?

Hard for me to say. I restored my session and this is the memory-report for that session. I would assume that the crashed session is 2-3 times larger:

Estimated Emacs Memory Usage

   133 MiB  Overall Object Memory Usage
    83 MiB  Total Buffer Memory Usage
    40 MiB  Reserved (But Unused) Object Memory
    34 MiB  Memory Used By Global Variables
    13 MiB  Memory Used By Symbol Plists
   2.6 KiB  Total Image Cache Size

Object Storage

    49 MiB  Conses
    42 MiB  Strings
    25 MiB  Vectors
    11 MiB  Intervals
   5.2 MiB  Symbols
   359 KiB  Buffer-Objects
    54 KiB  Floats

Largest Buffers

   7.1 MiB  REPL-useq
   5.6 MiB  alloc.c
   4.4 MiB  fish_history
   3.3 MiB   *code-conversion-work*
   2.1 MiB  vat.pdf
     2 MiB  VTerm ~/scratch
   1.9 MiB  ta.py
   1.9 MiB  loom.pdf
   1.6 MiB  REPL-9_useq<2>
   1.6 MiB  REPL-9_useq
   1.6 MiB  specification.py
   1.5 MiB  loom-oos.pdf
   1.4 MiB  REPL-jpeq
   1.2 MiB  uf.py
   1.2 MiB  xterm.c
   1.2 MiB  *Messages*
   1.1 MiB  REPL-peeq
   1.1 MiB  fc-monitor.py
   865 KiB  vat.tex
   843 KiB  VTerm /v/l/s/coredump

Largest Variables

     3 MiB  kill-ring
     3 MiB  kill-ring-yank-pointer
   2.4 MiB  undo-equiv-table
   2.2 MiB  package-lint-symbol-info
   2.2 MiB  load-history
   2.2 MiB  lsp--session
   1.8 MiB  lsp-modeline--diagnostics-wks->strings
   813 KiB  nerd-icons/mdicon-alist
   709 KiB  easy-menu-converted-items-table
   707 KiB  persp-buffer-props-hash
   653 KiB  *persp-hash*
   652 KiB  info-lookup-cache
   625 KiB  treemacs--themes
   547 KiB  treemacs--scope-storage
   513 KiB  face--new-frame-defaults
   436 KiB  centaur-tabs-display-hash
   402 KiB  file-notify-descriptors
   389 KiB  minor-mode-map-alist
   388 KiB  yank-menu
   374 KiB  centaur-tabs--buffers

Does this mean you run Emacs on a Red Hat system via the Cygwin X
implementation that runs on Windows? 
 
Correct.

Anything else that is "unusual" in your sessions?  Please don't save
us any such details, as they might be relevant, or provide important
clues as to where to look for the causes.

I am using doomemacs (https://github.com/doomemacs/doomemacs) so my configuration is very large and mostly not written by me. I don't think there is anything particularly unusual with it though.

In particular, last_marked and last_marked_index would be very
interesting.

 I have included that in the gdb trace above. Please, let me know if there is anything else I can dig out from the core.

Thanks!
George



On Fri, May 16, 2025 at 6:41 AM Pip Cet <pipcet@protonmail.com> wrote:
"George P" <georgepanagopo@gmail.com> writes:
> Hi,
>
> I am experiencing crashes during GC, and I have no idea what causes
> these crashes or how to reproduce them consistently.

If you can reproduce it at all, we probably need a live gdb session or
(slightly worse) a core dump to debug this further, because not all
information is in the backtrace.

> I have posted another
> crash without debugging symbols in https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00724.html. This time, I was running emacs in gdb, the
> trace is below. Seems to be related to bug#38936.

Are you capturing coredumps ("gcore" in gdb after the crash; it's best
to do this even if you keep the gdb session alive) or keeping the gdb
sessions alive?  That would help provide further information which might
allow us to track this down.

In particular, last_marked and last_marked_index would be very
interesting.

> (gdb) bt full
> #0  vector_marked_p (v=v@entry=0x4000000023000008) at alloc.c:4273

> No locals.
> #1  0x00000000005892bc in process_mark_stack (base_sp=base_sp@entry=2188) at alloc.c:7276
>         ptr = 0x4000000023000008
>         pvectype = <optimized out>
>         obj = 0x400000002300000d

That's a pseudovector header (for a font spec), but we've mistaken it
for a Lisp object.  The most likely reason is that a vector was freed
and partly re-used for this pseudovector, but it was still reachable
somehow, and we tried accessing it again after it was freed.

We need to look at last_marked, to find out which of the 76 slots in a
buffer object contained (directly or indirectly) this stale object, and
then try to figure out how it got there.

> Configured using:
>  'configure
>  --prefix=/nix/store/xdxaa55akicvs3jjrr8d7nmzla4gzbyl-emacs-30.1
>  --disable-build-details --with-modules --with-x-toolkit=lucid
>  --with-cairo --without-xft --with-compress-install
>  --with-toolkit-scroll-bars --with-native-compilation
>  --without-imagemagick --with-mailutils --without-small-ja-dic
>  --with-tree-sitter --with-xinput2 --without-xwidgets --with-dbus
>  --with-selinux'

I've looked a little at unusual code which would be enabled by this
configuration, but apart from this strangeness in
x_default_scroll_bar_color_parameter, I couldn't find anything:

      AUTO_STRING (foreground, "foreground");
      AUTO_STRING (background, "foreground");

I suspect no one's using X resources to set the background color of
scroll bars...

Pip