Re: Fix for Mac OS X Garbage Collection Crashes

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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