Luke Gorrie luke@bluetail.com writes: [snipped Bill's error detail]
This is interesting. Do you get the same problem if you just directly run this?
(macro-indentation '((COMPILER::VAR COMPILER::NEXT LIST) .
COMPILER::BODY))
Yes. I get the same segmentation violation in ACL:
SWANK(5): (macro-indentation '((COMPILER::VAR COMPILER::NEXT LIST) . COMPILER::BODY)) Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]
Restart actions (select using :continue): 0: Return to Top Level (an "abort" restart). 1: Abort entirely from this process.
From the backtrace it looks like the error is triggered by:
(remove '&whole '((COMPILER::VAR COMPILER::NEXT LIST) .
COMPILER::BODY))
Which I imagine should generate an error because the list isn't properly terminated, but a segfault seems a bit on the harsh side. Do you have some kind of high-speed low-safety optimization setup?
My settings are: ;; Optimization settings: safety 1, space 1, speed 1, debug 3.
Most importantly, is the return value of excl:arglist documented? Hopefully we can patch it up in swank-allegro.lisp to return something that looks like a proper lambda-list.
Here is the documentation for excl:arglist: arglist Arguments: function
Returns two values: if the the argument list of the operator (function, generic function, or macro) specified by the argument is known, it and t are returned. If the argument list is not known (that information can be discarded to save space), nil and nil are returned. Note that some argument lists may be uninformative (perhaps simply &rest args) when a function does all argument processing within its body. Also, the compiler may have simplified the argument list for its purposes. This function is designed to assist only. The argument list returned, even when the second returned argument is t, may not accurately describe all valid lists of arguments that can be passed to the function. (For example, the &allow-other-keys lambda-list keyword is often dropped.)
-- Bill Clementson