From: Cyrus H. <ch...@bo...> - 2005-08-30 20:01:06
|
This is a rather lame bug report as it's taken a bit out of context and I don't have an easily reproducible test case yet, but when I do the following: (defun power-spectrum (cm) (let ((rm (make-instance 'double-float-matrix :rows (clem:rows cm) :cols (clem:cols cm)))) (let ((a (clem::matrix-vals cm)) (b (clem::matrix-vals rm))) (dotimes (i (clem:rows rm)) (dotimes (j (clem:cols rm)) (setf (aref b i j) (abs (aref a i j)))))) rm)) I crash sbcl. There's a bug in my code here, which is that the make- instance call needs to pass 'clem:double-float-matrix not 'double- float-matrix. When I try a make-instance call like this from the REPL directly I get the correct error about the class not being found. Ok, here's a reproducible test case: (defun moose () (make-instance 'rat)) then from the repl: (moose) sends SBCL (0.9.4.12/ppc) off into the weeds. I'll try with a more up- to-date version. Thanks, Cyrus |
From: Juho S. <js...@ik...> - 2005-08-30 21:29:46
|
<ch...@bo...> wrote: > (defun moose () > (make-instance 'rat)) > > then from the repl: > > (moose) What a funny bug. The argument list to some function is (#1=#<FUNCTION #1# {10001E1869}>), which Slime then tries to print when showing a sldb stack-trace for the original error. The printer doesn't think that functions are compound objects, and thus won't do circularity detection on them in some circumstances, and runs out of stack while printing an infinitely repeating sequence of "FUNCTION ". The easy fix to this is to also treat functions as compound objects in SB-IMPL::COMPOUND-OBJECT-P. I'm not sure whether it's the right fix. -- Juho Snellman |
From: Juho S. <js...@ik...> - 2005-08-31 07:50:24
|
<js...@ik...> wrote: > What a funny bug. The argument list to some function is (#1=#<FUNCTION > #1# {10001E1869}>), which Slime then tries to print when showing a > sldb stack-trace for the original error. The printer doesn't think > that functions are compound objects, and thus won't do circularity > detection on them in some circumstances, and runs out of stack while > printing an infinitely repeating sequence of "FUNCTION ". > > The easy fix to this is to also treat functions as compound objects in > SB-IMPL::COMPOUND-OBJECT-P. I'm not sure whether it's the right fix. After a good night's sleep it seems obvious that this isn't the right fix, and the correct one would be to ensure that the function actually has a reasonable value in the name slot. This is a recent breakage, that I don't pretend to understand. Here's a simple test case for somebody who does: (sb-pcl::ensure-ctor `(sb-pcl::ctor ,(gensym)) nil nil) On 0.9.3 this will return a function with a name of 0 (the fixnum, not a symbol), on 0.9.4 one that has itself as a name. Neither one makes much sense, but at least the first one doesn't cause too much collateral damage. -- Juho Snellman |
From: Christophe R. <cs...@ca...> - 2005-08-31 08:43:16
|
Juho Snellman <js...@ik...> writes: > <js...@ik...> wrote: >> What a funny bug. The argument list to some function is (#1=#<FUNCTION >> #1# {10001E1869}>), which Slime then tries to print when showing a >> sldb stack-trace for the original error. The printer doesn't think >> that functions are compound objects, and thus won't do circularity >> detection on them in some circumstances, and runs out of stack while >> printing an infinitely repeating sequence of "FUNCTION ". >> >> The easy fix to this is to also treat functions as compound objects in >> SB-IMPL::COMPOUND-OBJECT-P. I'm not sure whether it's the right fix. > > After a good night's sleep it seems obvious that this isn't the right > fix, and the correct one would be to ensure that the function actually > has a reasonable value in the name slot. This is a recent breakage, > that I don't pretend to understand. Here's a simple test case for > somebody who does: > > (sb-pcl::ensure-ctor `(sb-pcl::ctor ,(gensym)) nil nil) > > On 0.9.3 this will return a function with a name of 0 (the fixnum, not > a symbol), on 0.9.4 one that has itself as a name. Neither one makes > much sense, but at least the first one doesn't cause too much > collateral damage. Ah, this reminds me of some very strange things that happened back when we implemented stored hash values for PCL instances and funcallable-instances. I think I wrote a comment about it... ;;; FIXME: This seems to bear no relation at all to the CLOS-SLOTS ;;; slot in the FUNCALLABLE-INSTANCE structure, above, which ;;; (bizarrely) seems to be set to the NAME of the ;;; FUNCALLABLE-INSTANCE. At least, the index 1 seems to return the ;;; NAME, and the index 2 NIL. Weird. -- CSR, 2002-11-07 (from src/pcl/low.lisp) I think there's probably some confusion lurking in the low-level representation of funcallable instances (and pcl-funcallable-instances). Tracing (not TRACING, sadly) what %funcallable-instance-info actually does is probably worthwhile. So I don't think this is recent breakage -- but I'm willing to believe that the symptom is recently exposed, probably by deleting INSTANCE-LAMBDA? Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2005-09-06 14:29:30
|
Cyrus Harmon <ch...@bo...> writes: > (defun moose () > (make-instance 'rat)) > > then from the repl: > > (moose) > > sends SBCL (0.9.4.12/ppc) off into the weeds. I'll try with a more up- > to-date version. Thanks for this report. I think I've fixed this symptom, but not yet all of the underlying cause, in sbcl-0.9.4.27. Cheers, Christophe |