From: Peter D. <pc...@cc...> - 2008-01-23 18:35:19
|
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.) 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? 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? 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.) 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.) -- Peter Dillinger pc...@cc... http://www.peterd.org |
From: Elliott S. <ell...@gm...> - 2008-01-24 22:20:20
|
On Jan 23, 2008 10:34 AM, Peter Dillinger <pc...@cc...> wrote: [...] > 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.) > > 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? Maybe this isn't exactly what you are talking about, but I can run SBCL (1.0, 1.0.6, 1.0.9, 1.0.13) fine on 64-bit windows machine. (I am running 32-bit windows so maybe this isn't your situation.) -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Peter D. <pc...@cc...> - 2008-01-24 23:51:13
|
On Thu, Jan 24, 2008 at 02:20:18PM -0800, Elliott Slaughter wrote: > Maybe this isn't exactly what you are talking about, but I can run > SBCL (1.0, 1.0.6, 1.0.9, 1.0.13) fine on 64-bit windows machine. (I am > running 32-bit windows so maybe this isn't your situation.) i'm rather certain it is not. running 32-bit windows on a 64-bit processor is, from a program's perspective, essentially the same as running it on a 32-bit processor. the only difference i could see would be access to SIMD instructions only put on 64-bit chips that happen to also be available from 32-bit mode. -- Peter Dillinger pc...@cc... http://www.peterd.org |
From: Nikodemus S. <nik...@ra...> - 2008-01-25 05:28:02
|
On 1/23/08, Peter Dillinger <pc...@cc...> 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 |
From: John C. <jo...@ya...> - 2008-01-27 16:41:58
Attachments:
parms.patch
|
Nikodemus Siivola wrote: > On 1/23/08, Peter Dillinger <pc...@cc...> 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 > Sbc...@li... > 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 | jo...@ya...| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+ |
From: Nikodemus S. <nik...@ra...> - 2008-01-29 13:10:53
|
On 1/27/08, John Connors <jo...@ya...> wrote: > 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 So these setting are at least somewhat good for 64bit Windows? Can someone confirm if they are good for 32bit Windows as well? Adding a build-option to use these instead (win64 instead of win32) is simple enough, though. (Dynamic-space is basically most of the code and data of the lisp image.) Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2008-02-02 22:40:50
|
On 1/29/08, Nikodemus Siivola <nik...@ra...> wrote: > On 1/27/08, John Connors <jo...@ya...> wrote: > > > 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 > > So these setting are at least somewhat good for 64bit Windows? Can > someone confirm if they are good for 32bit Windows as well? Apropos: what does uname -m return on 64 bit Windows? Or rather, which command-line tool can tell us that the host is a 64 bit Windows? Cheers, -- Nikodemus |
From: Michael L. <us...@cm...> - 2008-02-03 09:08:43
|
"Nikodemus Siivola" <nik...@ra...> writes: > Apropos: what does uname -m return on 64 bit Windows? Or rather, which > command-line tool can tell us that the host is a 64 bit Windows? the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64" on 64-bit Windows (probably something else on Itanium, but who cares). (and shouldn't the relocation patch fix this all for good?) cheers, --m |
From: <sbc...@pe...> - 2008-02-03 13:19:03
|
Op zondag 3 februari 2008, schreef Michael Livshin: > "Nikodemus Siivola" <nik...@ra...> writes: > > Apropos: what does uname -m return on 64 bit Windows? Or rather, which > > command-line tool can tell us that the host is a 64 bit Windows? > > the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64" > on 64-bit Windows (probably something else on Itanium, but who cares). > > (and shouldn't the relocation patch fix this all for good?) > > cheers, > --m Actually, PROCESSOR_ARCHITECTURE just has value "x86" but PROCESSOR_ARCHITEW6432 has value AMD64. My uname -a tells me: MINGW32_NT-5.2 XP64 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys so uname -m says i686. Peter |
From: Michael L. <us...@cm...> - 2008-02-03 14:08:27
|
sbc...@pe... writes: > Op zondag 3 februari 2008, schreef Michael Livshin: >> >> the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64" >> on 64-bit Windows (probably something else on Itanium, but who cares). > > Actually, PROCESSOR_ARCHITECTURE just has value "x86" but > PROCESSOR_ARCHITEW6432 has value AMD64. > My uname -a tells me: > MINGW32_NT-5.2 XP64 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys > so uname -m says i686. oh nice. according to this bit of official wisdom, you are correct: http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx that is: if you look inside the "Environment Variables" tab of "My Computer", you'll see PROCESSOR_ARCHITECTURE=AMD64. *but* query that variable from inside a 32-bit executable (of which your mingw "getenv" command is an example), you'll get "x86", at which point you should check the value of PROCESSOR_ARCHITEW6432. which is also, presumably, what the mingw implementation of "uname -m" does. cheers, --m |
From: <sbc...@pe...> - 2008-02-03 14:18:32
|
Op zondag 3 februari 2008, schreef Michael Livshin: > sbc...@pe... writes: > > Op zondag 3 februari 2008, schreef Michael Livshin: > >> the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64" > >> on 64-bit Windows (probably something else on Itanium, but who cares). > > > > Actually, PROCESSOR_ARCHITECTURE just has value "x86" but > > PROCESSOR_ARCHITEW6432 has value AMD64. > > My uname -a tells me: > > MINGW32_NT-5.2 XP64 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys > > so uname -m says i686. > > oh nice. > > according to this bit of official wisdom, you are correct: > http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bi >tness.aspx > > that is: if you look inside the "Environment Variables" tab of "My > Computer", you'll see PROCESSOR_ARCHITECTURE=AMD64. *but* query that > variable from inside a 32-bit executable (of which your mingw "getenv" > command is an example), you'll get "x86", at which point you should > check the value of PROCESSOR_ARCHITEW6432. which is also, presumably, > what the mingw implementation of "uname -m" does. > > cheers, > --m I build the latest git version of SBCL now and then and upload to http://www.peerweb.nl/sbcl/ . I haven't done a lot of testing, but with the win64 patch SBCL is still able to build SBCL, on 32 bits and 64 bits windows. All contribs except sb-simple-streams build fine, which is a known issue. A lot has improved since 1.0.9, still there is the issue of GUIDs recreated every time you create the sbcl.wxs file (supposedly not a good idea if you want to update parts of the install). So you'd need a list of GUIDs to use for every component (SBCL_Base and every test-passed contrib item). It seems somebody wants to have .lisp and .fasl files associated with sbcl.exe too, which is not included in the setup process (yet). I did some patching to exclude unneeded files from the installer. I have tried to add an icon to the installer as described here http://wix.sourceforge.net/manual-wix2/wix_xsd_icon.htm, but I am not sattisfied with the location of the icon in the shortcut to sbcl.exe (%APPDATA%\Microsoft\Installer\{<GUID>}\sbcl.ico) and attempts to set the location of the icon for the shortcut to another location failed. I think it's still best if the icon were just linked into the executable, if an icon is something you'd want. The dependency is in a platform specific file anyway, all you need is the icon file. I sent a patch for this earlier: http://sourceforge.net/mailarchive/message.php?msg_id=200708301348.07685.sbcl-devel%40peerweb.nl (but sf seems to have lost attachments to messages in the mailinglist archive) All patching is in sbcl-1.0.14.10-windows.patch at my /sbcl/ web location. Peter |
From: Juho S. <js...@ik...> - 2008-02-04 11:02:47
|
sbc...@pe... writes: > It seems somebody wants to have .lisp and .fasl files associated > with sbcl.exe too, which is not included in the setup process (yet). I think there used to be an association to .lisp, but that was removed since some users considered it somewhat antisocial for SBCL to set up that association unconditionally (and stealing it from other implementations). And it doesn't seem like a horribly useful thing to do: at least I would expect clicking on a Lisp file to open it in an editor, not to run it. -- Juho Snellman |