I stumbled across a very weird bug (?) while I was developing an application in Allegro Common Lisp, v9.0 for Windows. I do not get the regular lisp errors, instead I get system errors encapsulated in a lisp condition. I managed to create a simple test-case to reproduce the error (it's very silly):
(defun lambda-producer ()
(labels ((producer-label (x y)
(if (> x y) (- x y) (- y x)))
(producer-label2 (x y)
(max (producer-label x 2) (producer-label y 3))))
(lambda (x)
(reduce (lambda (a b) (producer-label2 a b)) x))))
;; Get errors when calling:
(funcall (lambda-producer) (list 2 1 5 12))
I get a Stack overflow error for this test case every time I try it.
In my original code I got a plethora of errors, mostly segmentation faults, once a 'can not take car
of <..> because it is not listp' and once Allegro crashed.
When running the same snippet (or my original code) in CLisp, everything runs fine and the REPL gives an answer.
My question: Am I doing something wrong or illegal here, or is there a bug in Allegro CL? If so, can we determine what that bug is and what to do about it?
Some experimentation seems to indicate that the reduce
and double labels are essential in reproducing the error; replacing reduce
with a funcall
or if there is only one label does not give an error.
This is a compiler bug. Please contact Franz.
At 49 and 52 of the second closure template, you can see that it's feeding itself to
sys::funcall-tramp
1 with 2 arguments2.sys::funcall-tramp
is an internal that I think might perform or otherwise allow tail calls.According to
ecx
at 57, sinceecx
is what seems to be used to check if the internalsys::trap-wnaerr
is called; I supposewna
stands for wrong number of arguments.