[Openmcl-devel] Kernel memory allocation failure
Gary Byers
gb at clozure.com
Wed Apr 30 08:00:44 PDT 2008
You're likely trying to allocate a stack (it seems to be trying to
allocate 1GB instead of 2^30.) A gigabyte here, 2 there ... sooner
or later, you're talking about real memory.
My guess is that this isn't the first time in the current session that
stacks of this size have been allocated, and that there are likely
several other stacks taking up real memory and address space in the
process; I doubt if the heap is exactly tiny ...
I don't know how much real memor or swap space you have or how much
you're using, or even what OS you're running on. Most OSes these
days tend to overcommit memory (claim that it's available even though
it may not be); the fact that this failed at allocation time rather
than later (when attemps were made to actually use allocated memory)
suggests that the OS believes that there's just no way that it can
afford to give you another 1GB and no way that could possibly work.
Whatever makes this appear to work sometimes and fail other times
is likely to be both perfectly understandable and dependent on
a lot of complicated factors.
If trying to use memory that you don't have doesn't work, the
options generally involve:
1) getting more memory
2) using less.
I suspect that the stack sizes that you're using have little to do
with actual needs (that you're not in fact dealing with tens or
hundreds of millions of levels of recursion). If this is true,
cutting those stack sizes by a few orders of magnitude would
be one simple way of using less memory.
On Tue, 29 Apr 2008, Jared C. Davis wrote:
> Hi,
>
> I can't reliably cause this error, but I'm wondering if there's
> something I can do to debug why it is occurring. After it is printed,
> my OpenMCL image immediately dies without putting me into a debug
> loop.
>
> Fatal error: : Kernel memory allocation failure.
> Can't allocate pointer of size 1073815552 bytes.
>
> I'm using SVN revision r8622 on x86-64.
>
> This seems like quite a large pointer, but, on the other hand, the
> machine ought to have more than enough memory to accommodate it.
>
> In case it is relevant, I have also increased the following limits to
> 2^30 in this OpenMCL image:
> - *default-control-stack-size*
> - *default-value-stack-size*
> - *default-temp-stack-size*
> - *initial-listener-default-control-stack-size*
> - *initial-listener-default-value-stack-size*
> - *initial-listener-default-temp-stack-size*
>
> But the image usually works fine and I've used it for a long time.
> It's only recently that I've been getting these errors. Perhaps I am
> pushing the system a little harder than before.
>
> Thanks!
>
> Jared
>
> --
> Jared C. Davis <jared at cs.utexas.edu>
> 11410 Windermere Meadows
> Austin, TX 78759
> http://www.cs.utexas.edu/users/jared/
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
More information about the Openmcl-devel
mailing list