GE> Martin Buchholz <martin(a)xemacs.org&gt; writes: GE> yes, indeed. Maybe Ray could build with DEBUG_GCPRO and then call GE> show_gcprohist(). It seemed that one gcpro struct in the gcprolist was GE> pointing to NULL, which shouldn't happen. I've never used DEBUG_GCPRO. GE> out of interest, is this always neccessary? Hm, I guess it is. Maybe GE> the actual bug is of this kind -- GCPROing an unintialised variable. When you GCPRO, your variables had better be initialized. Or at least when you gc. Even if you never actually use the variable you GCPROed. GE> I agree with the RETURN_UNGCPRO but don't think any of this is going GE> to make a difference. handler should be GCPRO'd by call3(). No! The old code carefully UNGCPRO'ed, and then used the unprotected variables. RETURN_UNCGPRO is not just syntactic sugar here. It evaluates the call to call3, during which time GCPRO is still in effect, then UNGCPROs and returns the result. I don't know whether the crash here was caused by unprotected handler, or by unprotected call3, or even if my patch actually fixes the problem. Martin