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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: George P <georgepanagopo <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 acorallo <at> gnu.org, 78444 <at> debbugs.gnu.org
Subject: Re: bug#78444: 30.1; Crash in GC (vector_marked_p)
Date: Fri, 27 Jun 2025 20:59:40 +0000

"George P" <georgepanagopo <at> gmail.com> 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 <at> 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 <at> 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

Previous Next

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