From: Henrik M. <hen...@we...> - 2003-05-11 19:22:36
|
Hi, Recent SBCLs (both 0.8alpha and CVS HEAD) don't seem to build on FreeBSD 5 (using 5.1 BETA here). Here's the error I get: cc -g -Wall -O3 -I. -c -o bsd-os.o bsd-os.c In file included from bsd-os.c:37: /usr/include/sys/proc.h:266: redefinition of `struct thread' bsd-os.c: In function `is_valid_lisp_addr': bsd-os.c:197: warning: decimal constant is so large that it is unsigned bsd-os.c:200: structure has no member named `control_stack_start' bsd-os.c:200: structure has no member named `control_stack_end' bsd-os.c:202: structure has no member named `binding_stack_start' bsd-os.c: In function `memory_fault_handler': bsd-os.c:231: warning: implicit declaration of function `gencgc_handle_wp_violation' gmake: *** [bsd-os.o] Error 1 sys/proc.h indeed defines a struct thread. It didn't in FreeBSD 4, and buidling SBCL works fine there. Regards Henrik |
From: Daniel B. <da...@te...> - 2003-05-13 11:36:18
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henrik Motakef <hen...@we...> writes: > sys/proc.h indeed defines a struct thread. It didn't in FreeBSD 4, and > buidling SBCL works fine there. Does bsd-os.c need to include sys/proc.h on FreeBSD? Is there some preprocessor define we can add/remove to make it skip the struct thread definition? Renaming the struct thread everywhere that we use it (which is, in short, everywhere) doesn't _really_ appeal, I have to say. On the other hand #define thread freebsd_thread #include <sys/proc.h> #undef thread is also fairly[*] ugly ... =2D -dan [*] 0.6 on a scale of 0 to vomit, I'd say =2D --=20 http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE+wNh7HDK5ZnWQiRMRAvG3AJ9RD6ChmtNS0OClI6nIQTg8+F60qQCdG7mP AZy+BUDCALduMrvdOFilnq0=3D =3DW1eM =2D----END PGP SIGNATURE----- |
From: Henrik M. <hen...@we...> - 2003-05-13 17:13:41
|
Henrik Motakef <hen...@we...> writes: > foreign.test.sh doesn't find the external symbol "summish". When > trying it interactivly, load-foreign returns nothing, i.e. (values), > it this supposed to be so? FWIW, it doesn't work in SBCL 0.7.11 either. Has anybody successfully used the FFI on FreeBSD yet? Regards Henrik |
From: Henrik M. <hen...@we...> - 2003-05-13 16:16:47
|
Daniel Barlow <da...@te...> writes: > Henrik Motakef <hen...@we...> writes: > >> sys/proc.h indeed defines a struct thread. It didn't in FreeBSD 4, and >> buidling SBCL works fine there. > > Does bsd-os.c need to include sys/proc.h on FreeBSD? Apparently not. I just removed the #include, and it seems to compile on both FreeBSD 5.1 BETA and 4.8. Now that was easy! :-) However, I still get a lot of warnings from GCC (3.2.2, by the way) when building the runtime. Nothing critical, I guess. I'll have a closer look at this. Additionally, two tests are failing: exhaust.impure.lisp just dumps core instead of signaling storage-condition. I havn't yet found the magic incantation to make gdb tell me anything more about this. foreign.test.sh doesn't find the external symbol "summish". When trying it interactivly, load-foreign returns nothing, i.e. (values), it this supposed to be so? Henrik |
From: Christophe R. <cs...@ca...> - 2003-05-16 09:40:34
|
Henrik Motakef <hen...@we...> writes: > Apparently not. I just removed the #include, and it seems to compile on > both FreeBSD 5.1 BETA and 4.8. Now that was easy! :-) > > However, I still get a lot of warnings from GCC (3.2.2, by the way) > when building the runtime. Nothing critical, I guess. I'll have a > closer look at this. The state of the runtime is quite parlous... it compiles, but not in the most elegant way possible, as you've discovered. There's nothing fundamental stopping a cleanup, I think; just finding the best way of declaring mostly-common-but-sometimes-slightly-different function prototypes, for instance. > Additionally, two tests are failing: > exhaust.impure.lisp just dumps core instead of signaling > storage-condition. I havn't yet found the magic incantation to make > gdb tell me anything more about this. How odd. Sourceforge has taken away the FreeBSD machine they used to have in the compile farm, so I can't check, but I'm fairly sure this used to work on FreeBSD. Conceivably, the default alternate stack handler position is somewhere in the middle of some other address space, or something? > foreign.test.sh doesn't find the external symbol "summish". When > trying it interactivly, load-foreign returns nothing, i.e. (values), > it this supposed to be so? Don't know :-/, sorry. Anyone? Christophe -- 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) |
From: Henrik M. <hen...@we...> - 2003-05-16 12:41:31
|
Christophe Rhodes <cs...@ca...> writes: >> Additionally, two tests are failing: >> exhaust.impure.lisp just dumps core instead of signaling >> storage-condition. I havn't yet found the magic incantation to make >> gdb tell me anything more about this. > > How odd. Sourceforge has taken away the FreeBSD machine they used to > have in the compile farm, so I can't check, but I'm fairly sure this > used to work on FreeBSD. Conceivably, the default alternate stack > handler position is somewhere in the middle of some other address > space, or something? Any easy way to check that? Or does anyone remember when the fix has been introduced, so that I can try to understand the issue by looking at it? FWIW, it also fails in SBCL 0.7.14 on both FreeBSD 4 and 5. >> foreign.test.sh doesn't find the external symbol "summish". When >> trying it interactivly, load-foreign returns nothing, i.e. (values), >> it this supposed to be so? > > Don't know :-/, sorry. Anyone? After digging a little, this seems to be a linker/dlsym issue. After load-foreign, sb-alien::*handles-from-dlopen* correctly has two entries, and sb-alien::dlsym finds the entries for libc stuff, but not for the other .so. The funny thing is that CMUCL's FFI works just fine, and it doesn't seem to do things that different. It does call ld differently in load-foreign, it uses /usr/bin/ld -G -o /tmp/... --whole-archive foo.so --no-whole-archive -lc instead of SBCL's /usr/bin/ld -shared -o /tmp/... foo.so -lc However, changing that in SBCL doesn't really seem to help. It does however work to load-1-foreign a .so created by CMUCL in /tmp, so there seems to be an easy solution, I just don't know what it is yet :-) Henrik |
From: Christophe R. <cs...@ca...> - 2003-05-16 13:10:21
|
Henrik Motakef <hen...@we...> writes: > Christophe Rhodes <cs...@ca...> writes: > >>> Additionally, two tests are failing: >>> exhaust.impure.lisp just dumps core instead of signaling >>> storage-condition. I havn't yet found the magic incantation to make >>> gdb tell me anything more about this. >> >> How odd. Sourceforge has taken away the FreeBSD machine they used to >> have in the compile farm, so I can't check, but I'm fairly sure this >> used to work on FreeBSD. Conceivably, the default alternate stack >> handler position is somewhere in the middle of some other address >> space, or something? > > Any easy way to check that? Or does anyone remember when the fix has > been introduced, so that I can try to understand the issue by looking > at it? > > FWIW, it also fails in SBCL 0.7.14 on both FreeBSD 4 and 5. The control stack guard checking was introduced in version 0.7.6.1, corresponding to a CVS checkin with the timestamp of "Tue Jul 23 17:22:37 2002 UTC". Some issues are discussed in Dan's diary entries, as here: <http://ww.telent.net/diary/2002/7/#23.59392>. > load-foreign, it uses > > /usr/bin/ld -G -o /tmp/... --whole-archive foo.so --no-whole-archive -lc > > instead of SBCL's > > /usr/bin/ld -shared -o /tmp/... foo.so -lc I have some vague recollections about this now; I seem to recall the cmucl people changing something in the recent past... but exactly what, I'm not sure. Surely if SBCL's linker command line were the same as CMUCL's, it would produce the same output? Or am I going quietly cuckoo here in the corner? Cheers, Christophe -- 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) |
From: Henrik M. <hen...@we...> - 2003-05-16 15:46:37
|
Christophe Rhodes <cs...@ca...> writes: >> Any easy way to check that? Or does anyone remember when the fix has >> been introduced, so that I can try to understand the issue by looking >> at it? >> >> FWIW, it also fails in SBCL 0.7.14 on both FreeBSD 4 and 5. > > The control stack guard checking was introduced in version 0.7.6.1, > corresponding to a CVS checkin with the timestamp of "Tue Jul 23 > 17:22:37 2002 UTC". Some issues are discussed in Dan's diary entries, > as here: <http://ww.telent.net/diary/2002/7/#23.59392>. OK, this doesn't look like something I'm gonna understand any time soon. I guess I'll stick to not writing infinitly recursive functions for now. >> load-foreign, it uses >> >> /usr/bin/ld -G -o /tmp/... --whole-archive foo.so --no-whole-archive -lc >> >> instead of SBCL's >> >> /usr/bin/ld -shared -o /tmp/... foo.so -lc > > I have some vague recollections about this now; I seem to recall the > cmucl people changing something in the recent past... but exactly > what, I'm not sure. Surely if SBCL's linker command line were the > same as CMUCL's, it would produce the same output? Or am I going > quietly cuckoo here in the corner? Well, it'd better do so. In fact, it does, I was trying stuff in a different image than I thought I did. What works is actually to load-1-foreign summish.so, i.e. the file given directly to load-foreign, without the extra ld step and without linking it with libc. I.e.: # src/runtime/sbcl --noinform --core output/sbcl.core * (sb-alien::load-1-foreign "/home/henrik/foreigntest.so") * (define-alien-routine summish int (x int) (y int)) SUMMISH * (summish 1 1) 3 * (quit) # src/runtime/sbcl --noinform --core output/sbcl.core * (load-foreign "/home/henrik/foreigntest.so") * (define-alien-routine summish int (x int) (y int)) debugger invoked on condition of type SIMPLE-ERROR: unknown foreign symbol: "summish" restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. (SB-SYS:FOREIGN-SYMBOL-ADDRESS-AS-INTEGER 1 "summish")[:EXTERNAL] |
From: Christophe R. <cs...@ca...> - 2003-05-17 17:14:14
|
Henrik Motakef <hen...@we...> writes: > Christophe Rhodes <cs...@ca...> writes: > >>> Any easy way to check that? Or does anyone remember when the fix has >>> been introduced, so that I can try to understand the issue by looking >>> at it? >>> >>> FWIW, it also fails in SBCL 0.7.14 on both FreeBSD 4 and 5. >> >> The control stack guard checking was introduced in version 0.7.6.1, >> corresponding to a CVS checkin with the timestamp of "Tue Jul 23 >> 17:22:37 2002 UTC". Some issues are discussed in Dan's diary entries, >> as here: <http://ww.telent.net/diary/2002/7/#23.59392>. > > OK, this doesn't look like something I'm gonna understand any time > soon. I guess I'll stick to not writing infinitly recursive functions > for now. Hmm. After spending a certain amount of time experimenting, it would appear that our control stack exhaustion checking is less robust than it might be. It is not currently clear to me whether the changes in behaviour between sbcls 0.7.12 (works as expected) and 0.7.13 (core dumps) on FreeBSD are a direct consequence of any change we made, or indirect effects of code rearrangements; nevertheless, I can confirm that 0.7.12 behaves itself on (defun foo () (+ (foo) (foo))) (foo) and 0.7.13 fails. Further, it would appear that sbcl-0.7.12.49 fails to behave interactively on ppc/linux and 0.pre8.47 on sparc/linux; on the other hand, 0.7.7 on sparc/linux succeeds to handle the error interactively. So it would appear that maybe one page isn't enough to be able to run an interactive debugger on anything except x86/linux? Increasing the protected area to 10*os_vm_page_size makes it behave (more-or-less) as expected on FreeBSD, in any case. The "more-or-less" there refers to the fact that on STACK-GROWS-DOWNWARD-NOT-UPWARD machines, there would seem to be an off-by-something error in SCRUB-CONTROL-STACK that means that the scrubbing sets off the guard, too. Ouch. Cheers, Christophe -- 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) |
From: Christophe R. <cs...@ca...> - 2003-05-20 09:48:03
|
Christophe Rhodes <cs...@ca...> writes: > Hmm. > > After spending a certain amount of time experimenting, it would appear > that our control stack exhaustion checking is less robust than it > might be. > > It is not currently clear to me whether the changes in behaviour > between sbcls 0.7.12 (works as expected) and 0.7.13 (core dumps) on > FreeBSD are a direct consequence of any change we made, or indirect > effects of code rearrangements; nevertheless, I can confirm that > 0.7.12 behaves itself on 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. Cheers, Christophe -- 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) |
From: Christophe R. <cs...@ca...> - 2003-05-23 08:52:15
|
> 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 <sq3...@la...>, 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 <86n...@ge...>, 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 <sq7...@la...> Christophe Rhodes wrote: > There remains a problem in SB-PCL::SET-ARG-INFO1, which is still > slightly baffling :-) in <86e...@ge...>, 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* (package-use-list *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? Cheers, Christophe -- 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) |
From: <ger...@t-...> - 2003-05-23 15:36:55
|
Christophe Rhodes <cs...@ca...> writes: > instead dying by running out of stack when trying to print the > stack exhaustion condition; I just checked that "dying" really means dying like before control stack checking. Just wanted to mention that there might be something to steal from CMUCL in this area :). I've implemented two guard zones, a "yellow" and a "red" one. The debugger is invoked when the yellow zone is hit. When the red zone is hit, one is thrown back to the toplevel, no questions asked. FWIW. |
From: Christophe R. <cs...@ca...> - 2003-05-25 22:42:05
|
Christophe Rhodes <cs...@ca...> writes: > 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). I believe that the patches merged in sbcl-0.8.0.1 and -0.8.0.2 should restore good behaviour on stack exhaustion where it was previously present (and incidentally fix the build on FreeBSD and the off-by-factor-of-four in SCRUB-CONTROL-STACK). If someone has an OpenBSD machine to test with, it would be particularly useful to hear feedback from there, as some of the modifications I've had to make will affect that platform's binary too. Other things: I've used a CMUCL-compatible API to unify the treatment of "generalized" function names, but I can't say I like it; DEFINE-FUNCTION-NAME-SYNTAX is fine, but I don't like VALID-FUNCTION-NAME-P, named as though it were a boolean function, returning two values, the second of which is syntactically important. As such, I'd like to canvass opinion for what, if any, function name syntax extension we should be exporting from SB-EXT. Please speak freely :-) Also, control stack exhaustion checking, even with these patches, appears to be completely broken on PPC/Linux (death by segfault) and partially broken on x86/Linux, where the detection and restoration work fine but any subsequent call to C appears to hang... :-/ Cheers, Christophe -- 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) |
From: <ger...@t-...> - 2003-05-23 11:01:28
|
Christophe Rhodes <cs...@ca...> writes: [Nice performance, hahaha! :)] > 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* > (package-use-list *pcl-package*)))) > (and sym (symbolp sym) > (not (null (memq (symbol-package sym) pkg-list))) > (not (find #\space (symbol-name sym)))))) > ...) Hm, I have something quite different here, actually, so I seem to have remembered that case at some point, although I can't recall having done anything. Anyway, the passage in question reads here ;; Let dfuns and emfs be pre-computed for "normal" PCL methods, not ;; the ones generated in the course of optimizations. This ;; implementation depends on the fact that the latter methods result ;; in NIL being returned as second value of ;; EXT:VALID-FUNCTION-NAME-P. (unless was-valid-p (let ((name (if (eq *boot-state* 'complete) (generic-function-name gf) (early-gf-name gf)))) (setf (gf-precompute-dfun-and-emf-p arg-info) (multiple-value-bind (valid sym) (valid-function-name-p name) (and valid sym (symbolp sym) (let ((pkg (symbol-package sym)) (pcl *the-pcl-package*)) (or (eq pkg pcl) (memq pkg (package-use-list pcl))))))))) (This has a different problem at present, because the definition of function names has been changed meanwhile, I think, so that the second value of VALID-FUNCTION-NAME-P is no longer NIL. Have to check.) > 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? I can't answer the first part. It's clear however that PCL needs to do a lot of extra work precomputing dispatch functions and effective methods when these functions change soon anyway, which is my personal interpretation of why this code was put there originally. Maybe this is such a situation? |
From: <ger...@t-...> - 2003-05-23 11:05:15
|
Gerd Moellmann <ger...@t-...> writes: > It's clear however that PCL needs to do a lot of extra work > precomputing dispatch functions and effective methods when these > functions change soon anyway, which is my personal interpretation of > why this code was put there originally. Maybe this is such a > situation? Or rather a situation where compilation etc. wouldn't normally happen, unless dfuns and emfs are pre-computed. That seems more likely, I think. |
From: Christophe R. <cs...@ca...> - 2003-05-23 11:10:59
|
ger...@t-... (Gerd Moellmann) writes: > (This has a different problem at present, because the definition of > function names has been changed meanwhile, I think, so that the second > value of VALID-FUNCTION-NAME-P is no longer NIL. Have to check.) My reading of cmucl code said that it was performing substantially the same operation, I think; the second return value is the block name, which for CLASS-PREDICATE is the cadr. >> 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? > > I can't answer the first part. It's clear however that PCL needs to > do a lot of extra work precomputing dispatch functions and effective > methods when these functions change soon anyway, which is my personal > interpretation of why this code was put there originally. Maybe this > is such a situation? Here's something that may be of interest: csr21@caligula:~$ sbcl This is SBCL 0.7.7, an implementation of ANSI Common Lisp. ;;; i.e. post CONTROL-STACK-EXHAUSTION checking, but pre ;;; generalized-function-names * (trace sb-walker:walk-form) (SB-WALKER:WALK-FORM) * (princ (make-condition 'sb-kernel::control-stack-exhausted)) Control stack exhausted (no more space for function call frames). This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away. #<SB-KERNEL::CONTROL-STACK-EXHAUSTED {40021AF1}> csr21@mu:/var/tmp/sbcl$ ./src/runtime/sbcl --core output/sbcl.core This is SBCL 0.8alpha.0.43, an implementation of ANSI Common Lisp. * (trace sb-walker:walk-form) (SB-WALKER:WALK-FORM) * (princ (make-condition 'sb-kernel::control-stack-exhausted)) 0: (SB-WALKER:WALK-FORM (SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) ... (#<STANDARD-METHOD (SB-PCL::CLASS-PREDICATE SERIOUS-CONDITION) (T) {9022731}>) ... [ plus 5 more calls to WALK-FORM -- two each in total for (CLASS-PREDICATE SERIOUS-CONDITION) (CLASS-PREDICATE STORAGE-CONDITION) and (CLASS-PREDICATE CONTROL-STACK-EXHAUSTED). ] No wonder we were running out of stack! :-) Cheers, Christophe -- 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) |
From: <ger...@t-...> - 2003-05-23 11:55:26
|
Christophe Rhodes <cs...@ca...> writes: > ger...@t-... (Gerd Moellmann) writes: > > > (This has a different problem at present, because the definition of > > function names has been changed meanwhile, I think, so that the second > > value of VALID-FUNCTION-NAME-P is no longer NIL. Have to check.) > > My reading of cmucl code said that it was performing substantially the > same operation, I think; the second return value is the block name, > which for CLASS-PREDICATE is the cadr. Yes, the meaning of the second value didn't change, only the definitions of the function name syntaxes in macros.lisp. I think Eric needed them to return block names at some point, and I didn't remember that something relied on nil being returned. [...] > csr21@mu:/var/tmp/sbcl$ ./src/runtime/sbcl --core output/sbcl.core > This is SBCL 0.8alpha.0.43, an implementation of ANSI Common Lisp. > * (trace sb-walker:walk-form) > > (SB-WALKER:WALK-FORM) > * (princ (make-condition 'sb-kernel::control-stack-exhausted)) > 0: (SB-WALKER:WALK-FORM > (SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) > ... > (#<STANDARD-METHOD > (SB-PCL::CLASS-PREDICATE > SERIOUS-CONDITION) (T) > {9022731}>) > ... > > [ plus 5 more calls to WALK-FORM -- two each in total for > (CLASS-PREDICATE SERIOUS-CONDITION) (CLASS-PREDICATE > STORAGE-CONDITION) and (CLASS-PREDICATE CONTROL-STACK-EXHAUSTED). ] > > No wonder we were running out of stack! :-) Yup, that's from the pre-computation of emfs, I think. Presumably, class predicates are currently not called in this context, so that all that stuff normally doesn't happen. |