Useless SBCL on Win32: memory problem

49 views
Skip to first unread message

quasiste...@gmail.com

unread,
Feb 28, 2007, 3:06:16 PM2/28/07
to
I`ve installed sbcl-1.0.2-x86-windows-binary.msi and here it is:

>sbcl.exe
VirtualAlloc: 0x1e7.
ensure_space: failed to validate 536870912 bytes at 0x09000000
(hint: Try "ulimit -a"; maybe you should increase memory limits.)

How can I avoid this bug? Is there any patch or something? Googling
reveals nothing.

And also I tried to find any SDL binding for my Clisp (which I`m using
now). Is there something except CL-SDL?

Timofei Shatrov

unread,
Feb 28, 2007, 4:23:19 PM2/28/07
to
On 28 Feb 2007 12:06:16 -0800, quasiste...@gmail.com tried to confuse
everyone with this message:


>
>And also I tried to find any SDL binding for my Clisp (which I`m using
>now). Is there something except CL-SDL?
>

Dunno about your SBCL question (I'm running earlier version), but SDL bindings
which work on CLISP can be found here: http://lispbuilder.sourceforge.net/

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|

Michiel Brentjens

unread,
Feb 28, 2007, 5:52:57 PM2/28/07
to
quasiste...@gmail.com wrote:

I have seen a similar problem on Suse Linux 9.2 / vanilla kernel 2.6.14.3:

$ sbcl --dynamic-space-size 881
mmap: wanted 923795456 bytes at 0x9000000, actually mapped at 0x4043d000
ensure_space: failed to validate 923795456 bytes at 0x09000000


(hint: Try "ulimit -a"; maybe you should increase memory limits.)

$ limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize unlimited
coredumpsize 0 kbytes
memoryuse unlimited
vmemoryuse unlimited
descriptors 1024
memorylocked 32 kbytes
maxproc 6143


This is just fine:
$ sbcl --dynamic-space-size 880
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* ...

I have 768 MB of RAM and 1.5 GB of swap, so that should not be the problem.

CMUCL:
$ lisp -dynamic-space-size 1024
gives no problems at all.


Michiel Brentjens

andrew...@gmail.com

unread,
Feb 28, 2007, 6:31:37 PM2/28/07
to

I had a similar problem with SBCL 1.0.2 port to windows, but only when
I tried SBCL + xemacs + slime. I found that when I used SBCL either
as a standalone or with gnu emacs, it was fine.

Best,

Andrew

Robert Dodier

unread,
Mar 1, 2007, 12:11:38 AM3/1/07
to
Michiel Brentjens wrote:

> I have seen a similar problem on Suse Linux 9.2 / vanilla kernel 2.6.14.3:
>
> $ sbcl --dynamic-space-size 881
> mmap: wanted 923795456 bytes at 0x9000000, actually mapped at 0x4043d000
> ensure_space: failed to validate 923795456 bytes at 0x09000000

On my Fedora 2 system (yes, it's ancient, oh well) the following
magic incantation makes Linux happy to run SBCL. Otherwise I
see the same complaint you mentioned. As superuser:

# echo 0 > /proc/sys/kernel/exec-shield

Dunno if that works for Suse too.

HTH
Robert Dodier

Tim Bradshaw

unread,
Mar 1, 2007, 10:48:39 AM3/1/07
to
On Feb 28, 8:06 pm, quasistellarli...@gmail.com wrote:

>
> How can I avoid this bug? Is there any patch or something? Googling
> reveals nothing.

I suspect this is because of one of these mutant address-randomization
things that various OSs now do to protect against buffer overflow
attacks. The SBCL mailing list can probably help you.

quasiste...@gmail.com

unread,
Mar 1, 2007, 11:27:49 AM3/1/07
to
Thank you. I had a look at lispbuilder-sdl. Although it`s not the
thing I was looking for, it suits me rather well.

malkia

unread,
Mar 1, 2007, 6:02:15 PM3/1/07
to
I've had a similiar problem with a "C" application under Win32. At
some point I need to allocate a huge block of 1.2GB of data, and
malloc() was failing. Then I've looked here and there, and the problem
is the way the virtual address space is organized. There are lots of
DLL's mapped into your virtual address space (the memory below 2GB),
and most importantly those mappings are different on different
machines (my tool had to be used by other people in the company). To
solve the problem, I had to force the OS to somehow rebase on the fly
those DLL's. As my Win32 Low-level knowledge is not that great, I
simply ended up declaring a static array of bytes in the size of 1.2GB
and then putting my own allocator on it (I've Doug Lea's one).

So if you understand the SBCL sources, and can patch them, to not use
HeapAlloc (I'm not sure what they are using), or something like it but
rather make a huge static array, and then force the allocator to use
that area, you might solve your problem. The OS would take care of
rebasing. It's not a good solution, but might just work for you.

You can go up to 1.5GB (or more/less depends again from machine to
machine), and if you have 3 or 4GB machine, and you've enabled the /
3GB switch in your Windows boot.ini, then you can go up to 2.5GB (or
more).

Dimiter "malkia" Stanev,
Treyarch, Activision LLC,
mal...@mac.com, mal...@gmail.com, mal...@treyarch.com


quasiste...@gmail.com

unread,
Mar 3, 2007, 11:15:59 AM3/3/07
to
I`ve found this solution somewhere on the SBCL mailing list:
"Try EDITBIN.EXE.
EDITBIN.EXE /STACK:6291456 /HEAP:67108864 sbcl.exe"
Having played half an hour with different numbers I concluded that
this advice doesn`t help.

George Neuner

unread,
Mar 4, 2007, 1:33:56 AM3/4/07
to
On 28 Feb 2007 12:06:16 -0800, quasiste...@gmail.com wrote:

>I`ve installed sbcl-1.0.2-x86-windows-binary.msi and here it is:
>
>>sbcl.exe
>VirtualAlloc: 0x1e7.
>ensure_space: failed to validate 536870912 bytes at 0x09000000
>(hint: Try "ulimit -a"; maybe you should increase memory limits.)
>
>How can I avoid this bug? Is there any patch or something? Googling
>reveals nothing.
>

Are you simultaneously running other apps that use shared DLLs?
Are you running with "system cache" enabled?

Common system DLLs are mapped once at fixed addresses (usually in the
reserved space above 2GB (or 3GB with the startup switch)) that are
shared by all apps, but less common system DLLs and private DLLs can
end up being mapped multiple times depending on their global load
order. If three apps use the same DLL, that DLL could be mapped one,
two or three times with each mapping reducing the global address space
available.

The "system cache" option has an interaction with any system DLLs that
may have been loaded below 2GB ... it tries to hang on to the first
mapping of the DLL as long as it can. This can cause fragmentation of
the global user address space such that there might not be enough
contiguous addresses to satisfy a large request.

If you are running with "system cache" enabled, try turning it off.
If that doesn't work, try starting SBCL first thing after booting. If
it still doesn't work, you'll just have to reduce the SBCL heap.

George
--
for email reply remove "/" from address

quasiste...@gmail.com

unread,
Mar 4, 2007, 4:51:06 AM3/4/07
to
Thank you, George.
I`m a bit disappointed that SBCL makes so high demands of operating
system`s settings. Looks like delivery with SBCL on win32 is a very
difficult problem. Nevertheless I`ll try to delve into SBCL`s guts.

Reply all
Reply to author
Forward
0 new messages