Re: Fix for Mac OS X Garbage Collection Crashes

[Andrew Choi]

Stefan Monnier <address@hidden> writes:

> Is this `line 5014' the `if (CONS...)' line in mark_object in the
> code below ?
>
>     case Lisp_Cons:
>       {
>       register struct Lisp_Cons *ptr = XCONS (obj);
>       if (CONS_MARKED_P (ptr)) break;
>       CHECK_ALLOCATED_AND_LIVE (live_cons_p);
>
> and in the earlier email you mention it's linked to `when
> LISP_INT values are on the gcprolist'.  What gave you this impression ?
>
> I understand you don't have time to work on this and I'm better
> placed to do the work, but any additional hint can be helpful: this is
> otherwise very difficult to track down.

Yes, it was very hard to repeat the error.  The following shows the top
of the call stack in one of my crash logs.

Thread 0 Crashed:
 #0   0x000c6aec in mark_object (alloc.c:5014)
 #1   0x000c5e20 in Fgarbage_collect (alloc.c:4400)
 #2   0x000dc710 in Feval (eval.c:1978)
 #3   0x000d99a0 in Fprogn (eval.c:409)
 #4   0x000de81c in unbind_to (eval.c:3083)
 #5   0x0010de14 in Fbyte_code (bytecode.c:893)
 #6   0x000de1f4 in funcall_lambda (eval.c:2916)
 #7   0x000ddcb8 in Ffuncall (eval.c:2781)
 #8   0x0010d70c in Fbyte_code (bytecode.c:691)
 #9   0x000de1f4 in funcall_lambda (eval.c:2916)
 ...

So the call to mark_object that causes the problem was made from line
4400, in the code here:

#if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
     || GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS)
  mark_stack ();
#else
  {
    register struct gcpro *tail;
    for (tail = gcprolist; tail; tail = tail->next)
      for (i = 0; i < tail->nvars; i++)
        mark_object (tail->var[i]);
  }
#endif

That's what gave me the idea that perhaps I should change the definition
of GC_MARK_STACK for the OS X build.  Then I ran Emacs under gdb and
after a long time was able to get the crash again (running Gnus, Tramp,
BlogMax, and possibly other stuffs).  I discovered that `obj' contains
an integer value (0x1fff0000, -32768?, I think) but strangely the case
for Lisp_Cons (line 5014) was reached.  Unfortunately I don't have that
process any more.  Perhaps one can try to repeat this on another
platform too.  It seems that this may not be a Mac-specific problem.
Hope this is enough information.  The change to alloc.c last month
wasn't that big, was it?