clisp crashes on startup

Reini Urban
Fri Jul 13 12:53:00 GMT 2012

On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote:
> On Jul 12 20:48, Daniel Colascione wrote:
>> On 7/10/12 8:41 AM, Daniel Colascione wrote:
>> > On 7/10/12 1:13 AM, Corinna Vinschen wrote:
>> >> On Jul  9 21:59, Daniel Colascione wrote:
>> >>> On 7/9/12 2:26 PM, Daniel Colascione wrote:
>> >>>> [snip]
>> >>>
>> >>> It turns out that clisp crashes only when I've rebased DLLs into the
>> >>> high portion of the 4GB WOW64 address space.
>> >>
>> >> Where did you rebase them to?  You know that on WOW64 and with the
>> >> bigaddr flag on, the application heap is located at 0x80000000 by
>> >> default, right?  Perhaps some of your DLLs just collide with that?
>> >
>> > I'm using a starting base address of 0xC8000000; I haven't had
>> > problems with any other program.
>> It turns out that clisp uses bit 31 of each pointer for its gc mark
>> bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_
> Ouch.
>> work, however, when compiled with -DWIDE. In this mode, clisp uses two
>> words for each lisp value --- one for the pointer and one for the
>> metadata.

Hmm, I do not really want to maintain lisp32.exe and lisp64.exe
variants, but maybe
upstream can be persuaded to make that distinction in the clisp.exe driver.
It's only for huge data and bad rebase addresses.
And for huge data a self-compiled clisp makes sense to me.
Serious lisp users use better lisp compilers anyway which compile
to native code. (sbcl, lispworks, allegro).
clisp's main strength is fast startup and fast IO.

>> Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also
>> works, and without bloating memory use, but that requires that no real
>> virtual address be in the range [0xC0000000, 0xDFFFFFFF].
> That can't be guaranteed.  WOW64 provides the full 32 bit VM address
> space.

Maybe also a documentation issue for rebaseing.
Reini Urban

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list