Marius Vollmer wrote:

>Neil Jerram <neil@ossau.uklinux.net> writes:
>
>  
>
>>Working on breakpoints for 1.6.x, I just discovered that the
>>following ENTER_APPLY trap code in eval.c goes into a tight busy loop
>>if (debug-enable 'trace) and (trap-set! apply-frame-handler non-#f).
>>
>>  if (CHECK_APPLY && SCM_TRAPS_P)\
>>    if (SCM_APPLY_FRAME_P || (SCM_TRACE_P && PROCTRACEP (proc)))\
>>
>>This is because PROCTRACEP uses scm_procedure_property, which itself
>>uses apply if proc is not a closure.
>>    
>>
>
>Hmm, I can't find the place where scm_procedure_property calls apply.
>Could you give me a hint?
>
Sorry! Please see the attached stack trace. scm_procedure_property calls 
scm_stand_in_proc, which calls scm_assoc, which calls scm_equal_p, which 
decides to do a generic dispatch, which eventually comes round to eval 
and apply again.

It looks like the generic dispatch happens because subrs are not one of 
the special cases in scm_equal_p, and because GOOPS has been loaded (? 
so that g_scm_equal_p != 0 -- I'm not quite sure how this happens).

>Hopefully, there is some misunderstanding
>on your part so that we can avoid making subrs untraceable.  (Which is
>what your proposed change does, right?)
>
>  
>
Yes, it does, and I agree that it would be better not to. Another option 
would be for scm_stand_in_proc to use scm_assq instead of scm_assoc. 
This seems reasonable, and works for me (i.e. avoids the busy loop), but 
is there perhaps some reason why an assoc (rather than assq) is really 
needed here?

Regards,
Neil