> The change in question appears to be the change going from
> sbcl-0.7.12.12 to 0.7.12.13: that is, the addition of generalized
> function names seems to have greatly expanded the stack required to
> call ERROR.
> I'll admit to a certain amount of bafflement at this point.
[ mostly addressed to Gerd ] "I told you so."
<fx: screen-whitening, jarring music, [flashback]>
[ Cold. January. Moellmanization of PCL continues apace; there is a
certain demand for generalized function names, to fix package
renaming issues, uninterned class name issues, and so on. ]
in <sq3cnasp12.fsf@...>, Christophe Rhodes wrote:
> Attached is a patch that solves the defclass issue, above. It does so
> by introducing a generalization on function names: whereas before,
> only symbols and (SETF symbol) names were legal, now added to these is
> (SB-PCL::CLASS-PREDICATE symbol).
in <86n0lir9my.fsf@...>, Gerd Moellmann wrote:
> C-u 100 Kudos to Christophe!
[ voiceover: but despite the adulation, unbeknownst to the intrepid
team of explorers, Christophe had in fact introduced a ticking
timebomb that would, five months later, explode. ]
in <sq7kbww5r7.fsf@...> Christophe Rhodes wrote:
> There remains a problem in SB-PCL::SET-ARG-INFO1, which is still
> slightly baffling :-)
in <86el64lyh9.fsf@...>, Gerd Moellmann wrote:
> Oh, sorry, I had forgotten that already. Will take a look real
> soon now :).
Alright, enough with the amateur dramatics. What's going on?
* observation the first: sbcl-0.7.12.12 successfully catches stack
exhaustion on SPARC/SunOS and x86/FreeBSD;
* observation the second: sbcl-0.7.12.13 fails to catch stack
exhaustion on SPARC/SunOS and x86/FreeBSD, instead dying by running
out of stack when trying to print the stack exhaustion condition;
* observation the third: sbcl-0.7.12.13, running cold-sbcl.core,
successfully catches stack exhaustion on SPARC/SunOS.
This last point turns out to be crucial, in the end. Let's back up a
bit and have a look at (sbcl's 0.7.12.13 version of) SET-ARG-INFO1
(substantially unchanged in CVS HEAD of both projects):
(defun set-arg-info1 (gf arg-info new-method methods was-valid-p first-p)
(esetf (gf-precompute-dfun-and-emf-p arg-info)
(let* ((sym (if (atom name) name (cadr name)))
(pkg-list (cons *pcl-package*
(and sym (symbolp sym)
(not (null (memq (symbol-package sym) pkg-list)))
(not (find #\space (symbol-name sym))))))
We have changed the name of the class predicate function for the class
FOO:BAR from SB-PCL::|FOO::BAR class predicate| to
(SB-PCL::CLASS-PREDICATE FOO:BAR). The class predicate is a generic
function, and so at some point SET-ARG-INFO1 will be called on it;
previously, the test (AND SYM ...) would return NIL, because the class
predicate name has a space in it; in the new world, if FOO is not
among the packages used by PCL, the test would return T. Of
particular relevance here is the fact that SB-PRETTY is not among the
use list for SB-PCL.
When trying the cold-core of sbcl-0.7.12.13, while it is true that
control stack exhaustion was caught, there is a difference in
behaviour from the normal, expected behaviour; namely, PRINT-OBJECT
methods have not yet been set up (since CLOS doesn't exist at that
stage), so the condition and restarts get printed by default
functions. Once CLOS is set up, the printing happens through CLOS
methods; however, it would appear that the change in this test for
CLASS-PREDICATE generic functions changes quite dramatically the
amount of work that PCL needs to do. In particular, poking around on
the stack I saw bits of macroexpansion apparently going on while the
system was trying to print the stack exhaustion condition.
So, to summarize, one mystery is solved: to fix the control-stack
exhaustion problem, ensure that the test highlighted above returns the
same after changing names of PCL-internal functions (I've tested this
on SPARC, and indeed we are back to a state of grace; I'll prepare a
patch that has this effect for post-0.8.0). Another mystery, however,
remains: why? Why does this test affect the behaviour of the system
so critically, and what is it actually doing?
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)