help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New memory exhausted problem


From: John Swensen
Subject: Re: New memory exhausted problem
Date: Mon, 13 Aug 2007 19:16:27 -0400
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)

John W. Eaton wrote:
On 13-Aug-2007, address@hidden wrote:

| I recently have run into a repeatable memory exhausted problem.  I am
| using Fedora Core 5 with the 2.9.9 version distributed iwht FC5.
| GNU Octave, version 2.9.9 (i686-redhat-linux-gnu).
| | The following is the sequence of commands that causes the error:
| octave:1> a = zeros(640,210,1800); octave:2> b = zeros(640,210,1800);
| error: memory exhausted -- trying to return to prompt
| octave:2>
| | While octave was still running, I ran the 'free' command in a different
| window.
| address@hidden Tools]$ free
|             total       used       free     shared    buffers     cached
| Mem:       3624816    1338440    2286376          0     157252     957628
| -/+ buffers/cache:     223560    3401256
| Swap:      4096564          0    4096564
| | | Clearly I still have over 2GB of free RAM and the swap disk hasn't even
| been touched.  Any suggestions as to what is causing the problem?

You are requesting a single allocation of approximately 1.8GB and you
only have about 2GB free.  I'm not sure of the details of the memory
management system in the linux kernel, but could it be that it fails
because although you have enough total space available, there is no
contiguous block of memory available that is large enough?  Maybe
someone who knows more about how the allocator is supposed to work
could give us a clue here.

jwe

It ends up that that must be the problem. I figured that it would at least go to the swap disk, yet still permit the allocations, but that isn't the case. It was *not* a limitation on the size of an allocation, because we tested allocation of a 3.5 GB chunk without any else allocated and it seemed to work fine. So it seems it must be a problem with a large allocation when there is little real memory left.

John Swensen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]