[Octave-bug-tracker] [bug #65669] Memory Leak when Using Cell

[Arun Giridhar]

Follow-up Comment #19, bug #65669 (group octave):

After a lot of testing, I think it really is Linux memory pool behavior, not
an Octave bug.

Test: In one Octave process, run this code from earlier in the thread:


tic; A = magic (1e4); toc, B = num2cell (A); toc, clear; whos


It should use about 4.6 GB *after* the "clear" statement. On my system, that
is about 29% of RAM for Octave.

Start a second Octave process and create an array of size roughly (total RAM
minus 4.6 GB), so e.g. if you have 16 GB, then create an array of size ~11.5
GB.


parr = perms (uint16 (1:12));  # this is roughly 11.5 GB final size


You can use any statement to do the second command as long as the size is in
the range of (total RAM minus RAM used by first Octave process). Note that my
perms() example will use some additional memory of its own while building the
array, so it uses some swap on my system.

On mine, first the total memory usage went up to 90%, then the first Octave
process's memory usage started falling from 29% down to low single digits,
while swap usage went up to about 6GB, then when everything was over some 20
seconds later, the second Octave was using about 11.5 to 12 GB, and the first
one was using only 35 MB not 4.6 GB like it had been occupying.

That sort of behavior is consistent with what I have seen from the Linux
kernel. Sometimes it is slow to relinquish freed memory when the program is
still running unless there really is memory pressure from other programs. But
you will have to tune the size of the second array in the second process
carefully. If you make it too small, there won't be any memory pressure and
the apparent memory allocated to the first process won't go down -- this might
look like a leak even if it is not. If you make it too big, there won't be
enough RAM or swap for both processes, and one or both will crash.

I also ran it through an AddressSanitizer build to be safe. In one run I ran
"A = ones (10)" and in the other, I ran "A = num2cell (ones (10))",
redirecting ASAN's stderr messages to files for both cases. Comparing the two
afterwards in vimdiff, the only differences were the physical memory
addresses, but the line-by-line usage numbers and messages were all identical.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65669>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/