GNU bug report logs - #41755
feature/native-comp (master?): temacs crash in GC during mark phase

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 41755 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase
Date: Mon, 08 Jun 2020 19:05:17 +0000

Nicolas Bértolo <nicolasbertolo <at> gmail.com> writes:

>> I'm wondering what we could do to make such bugs easier to find...
>
> We could add a canary to stack based strings and conses. Then while
> marking if we
> come across a stack based string or cons we check that the canary is
> intact. If
> it is not, then we can be sure that the memory has been written over.

I believe we should never be marking stack-based objects. If we do
that's a GC bug.

Code like

  AUTO_STRING (s, "foo");
  Lisp_Object c = Fcons (s, s);
  garbage_collect ();
  ...
  Fsetcar (c, Qnil);
  Fsetcdr (c, Qnil);

shouldn't work. I hope it doesn't :-) (With GC_CHECK_MARKED_OBJECTS, it
should abort; without, it would leave the mark bit of s set, so the
"..." code would presumably crash).

> Something like this:
>
> struct Stack_String
> {
>   struct Lisp_String string;
>   uint64_t canary = 0x12341234;
> };
>
>> Would GC_CHECK_MARKED_OBJECTS have caught this?
>
> As far as I can see, during a GC we can't know if a stack-based string
> is still alive.

But we can know whether a string is stack-based or not; if it is, we
shouldn't be marking it, so we can abort in that case...

Previous Next

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