4

I have a strange situation in my MEX/C-code compiled for Matlab. I use malloc(...) for dynamic memory allocation and I call free(...) to deallocate this memory. After exiting MEX routine I can see that allocated memory is not freed at all. On the other hand if I use mxMalloc(...) and mxFree(...) everything is fine. I assume that the usage of malloc(...) is not prohibitory if I take care of free(...). In Matlab specs I cannot find anything about intercepting or blocking basic C libraries. Although there are some strange posts about it, like on Matlab Central.

Vilen Jumutc
  • 41
  • 2
  • 1
    "After exiting MEX routine I can see that allocated memory is not freed at all" -- what makes you think that ? – Paul R Feb 05 '15 at 16:55
  • I can see it in my System Monitor (Linux) just by looking at Matlab process. In my `MEX` code I create BIG matrices and every time I see that 100+ MB allocated for these matrices are withhold by Matlab process. – Vilen Jumutc Feb 06 '15 at 08:19
  • I think you'll have to show some code. A minimal example that reproduces the problem. – chappjc Feb 06 '15 at 08:33
  • You can find code here: http://www.mathworks.com/matlabcentral/fileexchange/7978-power-iteration-to-find-max-min-eigenvalue-vector and to resolve the memory issue I have replaced `free(...)` and `malloc(...)` with `mxFree(..)` and `mxMalloc()`. – Vilen Jumutc Feb 06 '15 at 09:15

1 Answers1

3

It is OK to use malloc and free (new and delete[] too), just don't neglect to call the daellocation function first if you need to return early because of an error, exception, mexErrMsgTxt, etc. Look at every return, try/catch block, and mexErrMsg* in your code.

If you are sure there are no bugs in your code, try clear mex to see if you get your memory back.

Also, I suggest to build your MEX files in a way that allows you to attach a debugger. For example, if you are on Windows, you could follow these instructions to let you build directly in Visual Studio, which makes debugging easy (just attach to the running MATLAB.exe).

UPDATE: Addressing your comment about memory reported by top. Your mex file is using a different C runtime library from whatever MathWorks used to implement it's memory management for mxMalloc and mxFree. Note that free returns memory to the runtime library, not to the operating system. As a result, memory may be returned to the operating system at different times with different runtime libraries. From Modern Memory Managment at ONLamp.com:

malloc does not normally return the freed memory to the operating system; it remains owned by the process until it terminates. The process can reuse it the next time it requests more memory, but other programs will not have access to it, even if no other memory is available. As a corollary, then, the memory footprint of a program is the size of the largest allocation(s) made at any one time.

It is notoriously difficult to reduce the size of chunks of memory allocated to a process. See this answer. The answer reiterates the point: "To return the memory to the operating system, first all the memory allocated from one of these large chunks has to be released to the runtime library. The runtime library then can, if it wants, tell the operating system to release that chunk of memory." See the other answers there too.

Thus it is not surprising that the resident set size (RSS/RES) reported by top does not go down right away when free executes. The malloc used internally in MATLAB is clearly different from that used in the mex file, and may even be a custom implementation rather than a standard runtime version.

If it were an actual leak, you wouldn't get this memory back. If you pushed you system, that memory should return to the free pool. However, I would have to count this as a benefit of mxMalloc over malloc, with the disclaimer that I have not actually reproduced this effect myself.

Community
  • 1
  • 1
chappjc
  • 30,359
  • 6
  • 75
  • 132
  • Thanks for an answer. Code exits without an error and I've introduced additional `try/catch` blocks to prevent from exiting without deallocating memory. Nothing helps, even `clear mex` doesn't solve this issue. It seems that `free(...)` doesn't work at all in this case... or is blocked by Matlab. – Vilen Jumutc Feb 06 '15 at 08:15
  • @VilenJumutc The Mex file is a shared library that uses a C runtime library that is independent of MATLAB. I don't think MATLAB has any way to block it. What memory metric are you looking at? What column exactly of `ps` or `top` demonstrates the issue? – chappjc Feb 06 '15 at 08:38
  • I'm looking at RES column in `top`. – Vilen Jumutc Feb 06 '15 at 09:19
  • @VilenJumutc Freeing memory only frees memory *to the runtime library*. It is up to the library to return it *to the OS*, where it would be observable in RES in `top`. See my update. – chappjc Feb 06 '15 at 16:53
  • Thank you @chappjc for the answer. I have discovered this aftermath of `free(...)` after executing MEX calls hundred times in a row and observing that system starts to glitch starving from the lack of free memory. – Vilen Jumutc Feb 08 '15 at 09:58