Hi,
Stas Boukarev writes:
It says that Clisp crashes with a segfault, nothing to do with slime.
This is only half of the truth.
Ideally, clisp should not crash from a segmentation violation just by running Common Lisp code (it can crash when you modify the slots of internal objects used e.g. by its bytecode interpreter, but that doesn't count normally).
OTOH, there are ways to make many programs die hard, involving sockets or pipes. E.g. consider this scenario:
0. Program binds *terminal-io*, *debug-io*, *standard-output* etc. to pipe or socket stream. 1. Program encounters simple exception and reports that over pipe. 2. Program at other end of pipe closes connection. 3. Program tries to write additional data (e.g. error message) to now closed pipe, causing yet another exception. 4. Possibly endless sequence of nested exceptions as the basic *error-output* and *debug-io* are unusable. 5. Stack overflow. SIGSEGV.
Stuart has implicitly asked about how to have slime produce more trace output such that the origin of the SIGSEGV could be located in the application code. So far, I haven't seen an answer here.
Stuart uses:
GNU CLISP 2.49 (2010-07-07) (built on build.voidlinux.eu [148.251.136.24])
I would recommend that you use clisp from 2017-2019, even though there has been no official release yet (it's still in the release candidate phase). There have been quite some robustness and portability enhancements in recent years.
However, I do seem to have libsigsegv. Here's the full output of 'clisp --version': cc -mtune=generic -O2 -O [...] -DNO_SINGLEMAP -DNO_TRIVIALMAP -lsigsegv
SAFETY=0 TYPECODES WIDE_HARD SPVW_PAGES SPVW_MIXED libsigsegv 2.10 libffcall 1.11
Without one of either SINGLEMAP_MEMORY or TRIVIALMAP_MEMORY you get no generational GC. Libsigsegv may still be used for stack overflow detection, I'm not sure.
It appears to me that your build of clisp in voidlinux was done using overly pessimistic / conservative settings. With GC, you might be able to increase clisp's performance by 50%. You should recompile. (I can understand that distributions want to use very portable settings, but I think that's too much).
Regards, Jörg Höhle