Menu

#10 problem with memory deallocation

1.0
open
nobody
None
2014-07-24
2014-07-08
No

It seems that in MATLAB memory is not correctly deallocated after the call to toastDeleteBasis. Even the call to clear all in the workspace does not work and memory still stays to high levels. And if you call again toastSetBasis and then toastDeleteBasis, the memory increases again (summing up to the previous used memory) and then it does not go down, it stays high. The only way to deallocate the memory seems to close MATLAB. Any clue on way this is happening or any idea on what to do to deallocate the memory avoiding to close MATLAB? Thanks.

Discussion

  • Martin Schweiger

    I couldn't actually reproduce this problem.

    Before and after running the following code, the indicated memory allocation for matlab rose from 3408684 to 3412876. The increase occurred during the first cycle of the loop. Memory size didn't change in the following cycles.

    cd test/3D/meshes
    mesh = toastReadMesh('cyl4_blobs.msh');
    for i=1:10000
    basis = toastSetBasis(mesh,[64,64,64]);
    toastDeleteBasis(basis);
    end

    Do you get a different outcome when you run this code? Is this on Linux or Windows? Are you using a different basis for the regular grid than the default linear (e.g. 'CUBIC')?

     
  • Sabrina Brigadoi

    You are right, it did not change with your code. I always thought it was the toastBasis function, but instead is seems it is the toastReadMesh one. Using your code (only 1 cycle), my starting % memory was 1.9, after the toastReadMesh call went up to 3.3, then after toastSetBasis to 5.3. After the call to toastDeleteBasis, it went down to 3.3, but after the call to toastDeleteMesh it stayed there, at 3.3. After clear all, it became 3.2.

    Isn't toastDeleteMesh the function to deallocate the memory from the mesh? Is there anything else I should call?
    I am running it on Linux.

     
  • Martin Schweiger

    I still don't see it. The following code didn't show a memory leak on my machine:

    clear all
    close all
    % Memory allocation:
    % i=1 2 3 4
    for i=1:100 % 3027516
    hmesh=toastReadMesh('cyl4_blobs.msh'); % 3409160 3404812 3404796 3404796
    hbasis=toastSetBasis(hmesh,[64,64,64]); % 3420552 3470332 3470332 3470332
    toastDeleteBasis(hbasis); % 3413352 3404796 3404796 3404796
    toastDeleteMesh(hmesh); % 3404796 3404796 3404796 3404796
    end

    clear all % 3355192

    The numbers in the comments are the indicated Matlab memory in loop 1 to 4 after executing the corresponding line. There is a bit of fluctuation in the first two loops, presumably Matlab doing some internal caching. But after loop 3, nothing changes anymore, so I don't think there is a memory problem in those toast mex files.

    Note that looking at the Matlab memory allocation can be a bit misleading, since matlab is doing a lot of internal caching and on-the-fly compilation, and has its own garbage collection. So even after the final clear all, you don't get back to the original memory size. But that's not a specific toast problem. Even with

    r = random('unid',zeros(10000,10000));
    clear all

    I don't get back the original memory size.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.