Nasty GC bug

Nasty GC bug

[Dmitry Antipov]

It looks like live_cons_p (M, P) may be true if P is a cons cell from
the spare_memory[X], X = 1..4. So, mark_maybe_{object, pointer} may
call to mark_object for an uninitialized cons from spare blocks, with
random results (most probably a crash). This is very hard to reproduce
because it depends from the values found on a C stack.

The same looks to be true for live_string_p and spare_memory[5, 6].

Suggested fix is to use MEM_TYPE_NON_LISP for spare memory, e.g.:

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-08-21 23:39:56 +0000
+++ src/alloc.c	2012-08-24 07:23:48 +0000
@@ -3816,22 +3816,22 @@
      spare_memory[0] = malloc (SPARE_MEMORY);
    if (spare_memory[1] == 0)
      spare_memory[1] = lisp_align_malloc (sizeof (struct cons_block),
-						  MEM_TYPE_CONS);
+						  MEM_TYPE_NON_LISP);
    if (spare_memory[2] == 0)
      spare_memory[2] = lisp_align_malloc (sizeof (struct cons_block),
-					 MEM_TYPE_CONS);
+					 MEM_TYPE_NON_LISP);
    if (spare_memory[3] == 0)
      spare_memory[3] = lisp_align_malloc (sizeof (struct cons_block),
-					 MEM_TYPE_CONS);
+					 MEM_TYPE_NON_LISP);
    if (spare_memory[4] == 0)
      spare_memory[4] = lisp_align_malloc (sizeof (struct cons_block),
-					 MEM_TYPE_CONS);
+					 MEM_TYPE_NON_LISP);
    if (spare_memory[5] == 0)
      spare_memory[5] = lisp_malloc (sizeof (struct string_block),
-				   MEM_TYPE_STRING);
+				   MEM_TYPE_NON_LISP);
    if (spare_memory[6] == 0)
      spare_memory[6] = lisp_malloc (sizeof (struct string_block),
-				   MEM_TYPE_STRING);
+				   MEM_TYPE_NON_LISP);
    if (spare_memory[0] && spare_memory[1] && spare_memory[5])
      Vmemory_full = Qnil;
  #endif

Comments?

Dmitry

Re: Nasty GC bug

[Paul Eggert]

On 08/24/2012 12:26 AM, Dmitry Antipov wrote:
> Suggested fix is to use MEM_TYPE_NON_LISP for spare memory, e.g.:

Thanks for finding this bug.

That patch doesn't look quite right if ! USE_LSB_TAG, since
in that case lisp_align_malloc won't correctly report a
failure in the section of code that checks whether the
memory just allocated can be addressed through a Lisp
object's pointer.  Also, what about dont_register_blocks
and allocated_mem_type?

Instead, how about marking the spare conses with Vdead
and the spare strings with NULL data?  Admittedly I
haven't had time to think this through....

Re: Nasty GC bug

[Dmitry Antipov]

On 08/24/2012 12:56 PM, Paul Eggert wrote:

> Thanks for finding this bug.
>
> That patch doesn't look quite right if ! USE_LSB_TAG, since
> in that case lisp_align_malloc won't correctly report a
> failure in the section of code that checks whether the
> memory just allocated can be addressed through a Lisp
> object's pointer.  Also, what about dont_register_blocks
> and allocated_mem_type?
>
> Instead, how about marking the spare conses with Vdead
> and the spare strings with NULL data?  Admittedly I
> haven't had time to think this through....

This implies initialization of the data which we will never
use; what about the special memory type, e.g. MEM_TYPE_SPARE?

Dmitry

Re: Nasty GC bug

[Paul Eggert]

On 08/24/2012 03:58 AM, Dmitry Antipov wrote:
> what about the special memory type, e.g. MEM_TYPE_SPARE?

Yes, something like that could work.

Re: Nasty GC bug

[Jim Meyering]

Dmitry Antipov wrote:
> It looks like live_cons_p (M, P) may be true if P is a cons cell from
> the spare_memory[X], X = 1..4. So, mark_maybe_{object, pointer} may
> call to mark_object for an uninitialized cons from spare blocks, with
> random results (most probably a crash). This is very hard to reproduce
> because it depends from the values found on a C stack.

Nice work!
I wouldn't be surprised if this is the cause of some of the GC-related
problems I've reported over the last year or two.