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-tramp1 with 2 arguments2.sys::funcall-trampis an internal that I think might perform or otherwise allow tail calls.According to
ecxat 57, sinceecxis what seems to be used to check if the internalsys::trap-wnaerris called; I supposewnastands for wrong number of arguments.