GNU bug report logs - #78444
30.1; Crash in GC (vector_marked_p)

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: George P <georgepanagopo <at> gmail.com>
Cc: 78444 <at> debbugs.gnu.org
Subject: bug#78444: 30.1; Crash in GC (vector_marked_p)
Date: Fri, 16 May 2025 10:41:51 +0000

"George P" <georgepanagopo <at> 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 <at> entry=0x4000000023000008) at alloc.c:4273

> No locals.
> #1  0x00000000005892bc in process_mark_stack (base_sp=base_sp <at> 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

Previous Next

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