Praetorian <email@example.com> wrote in message <firstname.lastname@example.org>... > On Dec 14, 2:35=A0pm, 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 i= > t uses since i see a growing amount of memory being used by matlab (via tas= > k manager). > > > > > it reaches the limit of my computer and then either crashes or simply c= > ontinues 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).
I have a question close to that one.. You said that "The MEX API does do it's own garbage collection whenever MATLAB terminates a MEX file", fine, but what about a function called in a shared library (via calllib) that return a mxArray* and thus, alloc via mxCreate functions ? Is this mxArray destoyed in C++ workspace ? Thanks..