From: D Herring on
On 02/20/2010 04:34 AM, Antti "Andy" Ylikoski wrote:
> Pascal J. Bourguignon wrote:
>> "Antti \"Andy\" Ylikoski" <antti.ylikoski(a)hut.fi> writes:
>>> Two times I have succeeded in crashing the CLISP, without any really
>>> informative error message. "CLISP.exe stopped working" or such was
>>> what I got.
>>>
>>> One bug which I can remember that I had a function such as
>>>
>>> (defun prove (goals depth mark continuation assertions) ..... )
>>>
>>> and I had called it with (approximately) the argument list
>>>
>>> (prove '(append.....) 4 *trail* '(funcall ...) '(if () then ()))
>>>
>>> and as a result the program crashed because the argument "mark" was
>>> not given a value -- even though the global variable *trail* did have
>>> a value. (I discovered this with the debugger.)
....
>>
>> That's strange. Perhaps on MS-Windows this clisp.exe had not been
>> compiled with all the nice libraries that are needed to get good
>> handling of memory faults and stack overflows?
>>
>> This is not the kind of things clisp breaks on unix targets
>> (approximately, it happens only with FFI).
>>
>> Perhaps you should give a complete and precise bug report on
>> mailto:clisp-list(a)lists.sourceforge.net
>
> I'm not using the old MS-DOS.
>
> I'm running Microsoft Windows 7 in a laptop PC with an AMD dual-core
> processor running at 1.2 GHz, 3GB of RAM and 220 GB of hard disk.

MSWin version doesn't matter; the OS design is fundamentally different
than unix, and clisp may need more customization. A stack overflow is
not uncommon, even on a system with plenty of free RAM; the OS
typically allocates a fixed stack size. Your bug report would
probably help the developers, but make sure you can reproduce it with
the latest version (2.48).

- Daniel