|
|
Re: matlab/mex function doesn't free memory
Posted:
Dec 14, 2008 6:00 PM
|
|
On Dec 14, 2:35 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 14 Des, 19:09, "Alex Berkovich" <alex...@tx.technion> wrote:
>
> > Hello all,
>
> > I'm running a mex function that calls for c code (compiled in the same file as the mex function itself).
> > when a simulation is done, it seems matlab doesn't release the memory it uses since i see a growing amount of memory being used by matlab (via task manager).
>
> > it reaches the limit of my computer and then either crashes or simply continues to run forever.
>
> > any suggestion on how to solve this problem is very appriciated.
>
> Any data structures you allocate with malloc-type functions
> (or with new in C++) should be freed by the appropriate
> corresponding calls to free or delete before your MEX function
> returns.
>
> As for mxCreateXXXX, only use them for whatever you intend to
> return back to the matlab workspace. I've never understood how
> the matlab memory managment system works (it seems to be based
> on some Java-type garbage collector) and I've always ended up
> with segmentation faults when I used mxFree on local variables
> inside the MEX function.
>
> Rune
If you're using mxFree on variables created using mxCreate* functions
it'll always result in a memory leak. mxFree will only free the
mxArray header and not the data pointed to by the header. Use
mxDestroyArray to free variables allocated using mxCreate* and mxFree
for those allocated using mxCalloc, mxMalloc and mxRealloc. I only use
the MEX API functions to manage memory in C mex functions and it works
just fine.
However, in case of C++ files it's better to use new except for
mxArray variables as you mentioned, and then free these using delete
in the class destructor. The MEX API does do it's own garbage
collection whenever MATLAB terminates a MEX file (because of a call to
mexErrMsgIdAndTxt for instance) before the mexFunction stack is
unwound. In this case trying to free memory using mxDestroyArray or
mxFree in the destructor causes a segv (since the memory has already
been freed by the garbage collector).
|
|
