Does Matlab blocks or intercepts free() in MEX/C-code

Question

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.

Answer 1

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.