Fix for Mac OS X Garbage Collection Crashes

Fix for Mac OS X Garbage Collection Crashes

[Andrew Choi]

If you've updated and built Emacs from CVS on OS X within the past few
weeks, you may have experienced crashes while Emacs is doing garbage
collection. The following patch, just checked into CVS, solves the
problem. I highly recommend updating to include it.

Index: darwin.h
===================================================================
RCS file: /cvs/emacs/src/s/darwin.h,v
retrieving revision 1.12
diff -r1.12 darwin.h
319a320,323
> /* Use the GC_MAKE_GCPROS_NOOPS (see lisp.h) method for marking the
>    stack.  */
> #define GC_MARK_STACK   GC_MAKE_GCPROS_NOOPS
> 

The problem is caused by a change to src/alloc.c about a month ago that
causes garbage collection to crash under certain circumstances (when
LISP_INT values are on the gcprolist) if GC_MARK_STACK is set to
GC_USE_GCPROS_AS_BEFORE. The best way to fix the problem is probably to
fix the bug introduced. I don't want to work on that. Instead I have now
set GC_MARK_STACK to GC_MAKE_GCPROS_NOOPS. This option for GC has been
chosen on nearly all other platforms. So by following suit on OS X, we
may actually be using better-maintained code in the future. This is
probably a better solution.

Re: Fix for Mac OS X Garbage Collection Crashes

[Stefan Monnier]

>> #define GC_MARK_STACK   GC_MAKE_GCPROS_NOOPS

This is probably a good change indeed.

> The problem is caused by a change to src/alloc.c about a month ago that
> causes garbage collection to crash under certain circumstances (when
> LISP_INT values are on the gcprolist) if GC_MARK_STACK is set to
> GC_USE_GCPROS_AS_BEFORE. The best way to fix the problem is probably to
> fix the bug introduced. I don't want to work on that. Instead I have now

That's interesting.  It needs definitely to be fixed.  Could you
give us as much info about this problem as you've encountered during
your debugging effort ?


        Stefan

Re: Fix for Mac OS X Garbage Collection Crashes

[Andrew Choi]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> The problem is caused by a change to src/alloc.c about a month ago that
>> causes garbage collection to crash under certain circumstances (when
>> LISP_INT values are on the gcprolist) if GC_MARK_STACK is set to
>> GC_USE_GCPROS_AS_BEFORE. The best way to fix the problem is probably to
>> fix the bug introduced. I don't want to work on that. Instead I have now
>
> That's interesting.  It needs definitely to be fixed.  Could you
> give us as much info about this problem as you've encountered during
> your debugging effort ?

I haven't spent much time on it.  Sorry I cannot be any more specific
than this: it crashed at line 5014 of src/alloc.c and at that time `obj'
seemed to contain a LISP_INT value.  I don't have a recipe for repeating
the error.  Sorry.

Re: Fix for Mac OS X Garbage Collection Crashes

[Stefan Monnier]

>>> The problem is caused by a change to src/alloc.c about a month ago that
>>> causes garbage collection to crash under certain circumstances (when
>>> LISP_INT values are on the gcprolist) if GC_MARK_STACK is set to
>>> GC_USE_GCPROS_AS_BEFORE. The best way to fix the problem is probably to
>>> fix the bug introduced. I don't want to work on that. Instead I have now
>> 
>> That's interesting.  It needs definitely to be fixed.  Could you
>> give us as much info about this problem as you've encountered during
>> your debugging effort ?
> I haven't spent much time on it.  Sorry I cannot be any more specific
> than this: it crashed at line 5014 of src/alloc.c and at that time `obj'
> seemed to contain a LISP_INT value.  I don't have a recipe for repeating
> the error.  Sorry.

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.


        Stefan

Re: Fix for Mac OS X Garbage Collection Crashes

[Andrew Choi]

Stefan Monnier <monnier@IRO.UMontreal.CA> 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?

Re: Fix for Mac OS X Garbage Collection Crashes

[Stefan Monnier]

> 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.

I've seen very strange things happen as well in other circumstances.

> 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?

Thanks.  I'll try running with GCPROs for a while.


        Stefan