Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: John Connors <johnc <at> yagc.ndo.co.uk>
Subject: Re: win32 questions/concerns
Newsgroups: gmane.lisp.steel-bank.devel
Date: Sunday 27th January 2008 16:40:53 UTC (over 9 years ago)
Nikodemus Siivola wrote:
> On 1/23/08, Peter Dillinger  wrote:
> 
>> i've deployed ACL2 (google it for info) to lots of students based on
>> SBCL 1.0.9 for windows (since that was the latest binary
>> distribution).  i found it to be quite stable (except w.r.t.
>> breaks/errors; 1.0.13 seems to have fixed these issues), and i like
>> the fact that it doesn't depend on a C compiler.
>>
>> students discovered, however, that it doesn't work under 64-bit
>> windows.  when they try to load my saved image, they get something
>> like
>>
>> | VirtualAlloc: 0x1e7.
>> |
>> | ensure_space: failed to validate 536870912 bytes at 0x09000000
>> |
>> | (hint: Try "ulimit -a"; maybe you should increase memory limits.)
> 
> As you may already know, SBCL currently has to reserve a contiguous
> address space at a known address for its use -- this message is an
> attempt to do that failing.
> 
> The failure is basically be that particular version of Windows loading
> something else (iirc SHELL32.DLL is a common culprit) in that address
> range before SBCL tries to reserve it.
> 
> ...how much this has to do with Windows being a 64 bit version there
> I'm not willing to guess at.
> 
>> also, another student with 4G of memory got a similar error.  and a
>> similar error arises if Data Execution Protection is enabled.
>>
>> questions:
>>
>> is win32 SBCL currently being tested on 64-bit versions of windows
>> (which are supposed to be able to run 32-bit applications without
>> modification-- ha!)?  what about 32-bit versions with > 2G memory
>> installed?
> 
> The amount of physical memory is not likely to have a great effect, but
> I don't know enough about Windows to swear that it doesn't have any...
> 
>> does saving an image on one machine and loading it on another machine
>> with a potentially different address space layout affect its ability
>> to load?
> 
> No.
> 
>> have some of these issues been addressed since 1.0.9?  (i don't have
>> ready access to these "odd" systems to test my 1.0.13 build very
>> soon.)
> 
> I can't immediately think of anything likely to change these issues
> much.
> 
> Two major options:
> 
> 1. Try using eg. --dynamic-space-size 128 (or other number, big enough
>    to run ACL2, small enough for there to be a contiguous chunk of
>    address space starting at #x09000000 to be available.)
> 
> 2. Rebuilding SBCL from the source, using David Lichteblau's relocation
>    patches, which should remove the need for a contiguous address space.
>    (I think someone reported Windows problems with the patch, but I
>    also think David said they were unexpected, and that he was going to
>    look at them?)
> 
> Other options include using the official source, but twiddling with the
> hardcoded address space ranges in src/compiler/x86/parms.lisp, and
> Various Magical Windows Tools some people have previously mentioned on
> this list, which may be able to edit the sbcl.exe in a way that causes
> Windows to leave the desired address space free.
> 
>> are there any plans to add Ctrl+C (ConsoleCtrlHandler) support?
>> (right now i'm planning to deploy a version with a very simple patch
>> that allows the main thread to ask periodically whether a console
>> interrupt has happened, which allows me to cover about 75% of the
>> cases i care about.)
> 
> I am not aware of any current plans to do so, but patches are certainly
> welcome!
> 
> Note: it was approximately a year ago that I did any Windows work of note
> on SBCL, and one of the things I looked at that point was
ConsoleCtrlHandler.
> IIRC it was quite unwilling to work with SBCL at that point, but I didn't
> finish my investigation as to the why of it.
> 
> Cheers,
> 
>  -- Nikodemus
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> 
For what it's worth, (I'm not sure how much) on win64 boxen I changed
src/compiler/x86/parms.lisp to the attached patch. I'm not sure what 
actually lives in the dynamic space, but I'm inclined to guess it's 
WoW32, hence the high failure rate on win64 boxen. HTH

I'm keeping an eye on mingw64 but as yet, I don't think its mature 
enough to be in with a chance of compiling SBCL.



-- 
+--------------------------------------------------------+
|Cyborg Animation Programmer    |    [email protected]|
|http://badbyteblues.blogspot.com
-----------------------|
+--------------------------------------------------------+
 
CD: 5ms