public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Reini Urban <rurban@x-ray.at>
To: cygwin@cygwin.com
Subject: Re: clisp crashes on startup
Date: Fri, 13 Jul 2012 16:30:00 -0000	[thread overview]
Message-ID: <CAHiT=DFpN3RMcH7RkQckcNk0qN9e-iuuZyk9n8d9y4m4agBAgQ@mail.gmail.com> (raw)
In-Reply-To: <20120713142626.GO3406@calimero.vinschen.de>

On Fri, Jul 13, 2012 at 9:26 AM, Corinna Vinschen wrote:
> On Jul 13 07:52, Reini Urban wrote:
>> 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.
>
> That has nothing to do with rebasing.  If you build clisp with a recent
> gcc, it will have the "bigaddr" flag set in the file header since
> Cygwin's gcc sets that by default.  While DLLs should be rebased from
> 0x70000000 downwards as usual, the applications heap, as well as
> thread stacks, as well as shared memory regions created with mmap(2)
> or shmat(2) will be in the high memory area starting at 0x80000000.
>
> THe bottom line is, if the distro clisp isn't 32 bit clean, which it
> apparently isn't using default settings, it should either be rebuilt
> with -DWIDE, or it should have the bigaddr flag removed from the
> file header by default (peflags -l0).

Thanks. This deserves an update now.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2012-07-13 16:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06 22:47 Daniel Colascione
2012-07-07 13:04 ` marco atzeri
2012-07-07 13:41   ` Daniel Colascione
2012-07-07 16:19     ` Reini Urban
2012-07-07 17:45       ` marco atzeri
2012-07-07 19:08         ` Daniel Colascione
2012-07-09 21:01           ` Reini Urban
2012-07-09 21:27             ` Daniel Colascione
2012-07-10  4:59               ` Daniel Colascione
2012-07-10  8:14                 ` Corinna Vinschen
2012-07-10 15:42                   ` Daniel Colascione
2012-07-13  3:48                     ` Daniel Colascione
2012-07-13  7:41                       ` Corinna Vinschen
2012-07-13 12:53                         ` Reini Urban
2012-07-13 14:27                           ` Corinna Vinschen
2012-07-13 16:30                             ` Reini Urban [this message]
2012-07-13 17:46                               ` Daniel Colascione
2012-07-07 17:05     ` Andrey Repin
2012-07-07 19:04       ` Daniel Colascione
2012-07-08 23:20         ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHiT=DFpN3RMcH7RkQckcNk0qN9e-iuuZyk9n8d9y4m4agBAgQ@mail.gmail.com' \
    --to=rurban@x-ray.at \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).