The gcl random tester found the following problem:
[6]> (funcall
(compile
nil
'(lambda (d)
(declare (optimize (speed 3) (space 0) (safety 3)
(debug 2) (compilation-speed 0)))
(gcd 39
(catch 'ct2
(block b7
(throw 'ct2
(unwind-protect
(return-from b7 17)
(return-from b7
(progv '(*s6*) (list 31) d))
)))))))
65)
*** - GCD: CT2 is not a INTEGER
The following restarts are available:
USE-VALUE :R1 You may input a value to be
used instead.
Break 1 [7]>
If the outer GCD is omitted this causes a seg fault.
The lambda form executes correctly if interpreted.
According to section 5.2 of the CLHS, the return-from
in the cleanup forms of the unwind-protect is legal,
since the extent of the block does not end until after
all the cleanup forms have been executed.
This occured in a clisp on linux x86 built from cvs
head on 9 jan 2004.
Logged In: YES
user_id=5735
here is what I see without GCD on the current CVS head:
*** - Corrupted STACK in #<COMPILED-CLOSURE NIL> at byte 40
Disassembly of function :LAMBDA
(CONST 0) = CT2
(CONST 1) = 17
(CONST 2) = (*S6*)
(CONST 3) = 31
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
22 byte-code instructions:
0 (CONST 0) ; CT2
1 (CATCH-OPEN L32)
3 (PUSH)
4 (UNWIND-PROTECT-OPEN L12)
6 (CONST 1) ; 17
7 (UNWIND-PROTECT-CLEANUP)
8 (SKIP 1)
10 (JMP L29)
12 L12
12 (CONST&PUSH 2) ; (*S6*)
13 (CONST&PUSH 3) ; 31
14 (LIST 1)
16 (PROGV)
17 (LOADI 1 0 5)
21 (UNBIND1)
22 (SKIPI 1 0 0)
26 (SKIPSP 2 0)
29 L29
29 (CATCH-CLOSE)
30 (SKIP&RET 2)
32 L32
32 (SKIP&RET 2)
it appears that all the elements (CATCH, BLOCK, PROGV) are
significant!
Bruno, coule you please comment on this?
Logged In: YES
user_id=5735
thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).