Subject: Re: bug#78444: 30.1; Crash in GC (vector_marked_p)

From: Pip Cet <[email-masked]>
Date: Fri, 27 Jun 2025 20:59:40 +0000

"George P" <[email-masked]> writes:

> Thanks, Maritn! I have now compiled emacs with your patch, and with --enable-checking, and will let you know if I get a hit.
>
> I got another crash (before compiling with Martin's patch and without
> --enable-checking, but with Pip's patch and -fno-tree-sra). I got the
> crash after rapidly pressing 2 keystrokes. I am not sure exactly which
> keystrokes, but I think it was ' followed by Del. It could be
> completely unrelated to this bug, but the trace seems pretty weird, as
> the m pointer represents ASCII text for "ganap/u/", which is the
> reversed start of my home directory "/u/panagopo".

The reversal is due to the little-endian byte order.  In memory, the
string is "/u/panag".

> Could it be that we have some sort of memory corruption that is throwing us in different directions?

Very likely.  Once we have found a good way of triggering this bug, we
might try running it in rr; with luck, we'd be able to identify a word
in memory which was corrupted and time-travel back to where it was
written to, or to the last GC cycle when the object containing it was
freed.

However, the slowdown and storage required by rr is significant, and
it's entirely possible the reproducer will fail to work then.

What is surprising is that we haven't seen a segfault caused by the
piece of code which corrupts memory writing to unmapped memory; even if
it writes to a previously-valid pointer, in a normal Emacs session,
memory is occasionally unmapped so it would cause a segfault.  That
might not apply here, however.

So far, all the corrupt words have been in pseudovectors.  It's possible
something is writing to a pseudovector which has been incorrectly deemed
unreachable and freed during a GC cycle.  However, a pseudovector
shouldn't usually contain an ASCII string, so maybe this is an exception.

Maybe increasing the frequency of garbage collections would help flush
out this bug.

> In any case, I will try to find a reproducer for this. Here is the trace:
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> adjust_markers_for_insert (from=11354, from_byte=11354, to=11355, to_byte=11355, before_markers=before_markers@entry=false) at insdel.c:301
> warning: 301 insdel.c: No such file or directory
> (gdb) bt full
> #0  adjust_markers_for_insert (from=11354, from_byte=11354, to=11355, to_byte=11355, before_markers=before_markers@entry=false) at
> insdel.c:301
>         m = 0x67616e61702f752f
>         nchars = 1
>         nbytes = 1

So there was a marker whose m->next pointer was overwritten by an ASCII
string.  Puzzling, because we don't usually write strings into vector
blocks.

Pip