Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
when to use mxFree() in mex files
115 views
Skip to first unread message
Bruce Elliott
Jan 24, 2014, 12:07:07 PM1/24/14
to
I have read the Matlab documentation on Memory Management and Memory Management Issues for Mex files, but I'm still pretty confused about when it is necessary for my functions to free memory that was dynamically allocated.
For example, if I use mxArrayToString() to create C character array from an mxArray, I must call mxFree() on the memory allocated for that array when I'm done with it.
If I use mxGetData() for the same purpose with numeric data, however, I do not free the memory referenced by the returned pointer.
Is there a categorical difference between these functions that should make it clear why I free memory in one case but not the other, or is this something we just have to learn for each such function?
For example, if I use mxArrayToString() to create C character array from an mxArray, I must call mxFree() on the memory allocated for that array when I'm done with it.
If I use mxGetData() for the same purpose with numeric data, however, I do not free the memory referenced by the returned pointer.
Is there a categorical difference between these functions that should make it clear why I free memory in one case but not the other, or is this something we just have to learn for each such function?
James Tursa
Jan 24, 2014, 12:54:08 PM1/24/14
to
"Bruce Elliott" <bruce....@jhuapl.nospam.edu> wrote in message <lbu6jr$8bl$1...@newscl01ah.mathworks.com>...
Your posts continue to drive home the point that I need to release my mex guide sooner rather than later. The MATLAB doc on this is inadequate and my mex guide adresses all of these issues.
To answer your specific question regarding mxFree, it should only be used on pointers that are returned by MATLAB API functions that dynamically allocate raw memory (not mxArray variables). Those functions that work with mxFree are:
mxCalloc
mxMalloc
mxRealloc
mxArrayToString
Functions that get pointers that are part of an mxArray should *NEVER* be passed to mxFree because that would invalidate and corrupt the mxArray (a data pointer pointing to invalid memory). E.g.,
mxGetData
mxGetImagData
mxGetPr --> equivalent to (double *)mxGetData
mxGetPi --> equivalent to (double *)mxGetImagData
mxGetChars --> equivalent to (mxChar *)mxGetData
mxGetLogicals --> equivalent to (mxLogical *)mxGetData
mxGetIr
mxGetJc
mxGetFieldNameByNumber
mxGetDimensions
You can detach the data pointer from the mxArray first and *THEN* use mxFree on it, but this typically isn't done so I won't post the details here (you need to clean up the data pointer and dimensions of the mxArray etc).
Similarly, functions that get cell or struct mxArray pointers should not be destroyed with mxDestroyArray since that would invalidate the cell or struct they are part of (pointers pointing to invalid memory). This is because they get the actual pointer from the cell or struct, not a deep copy of it. So don't mxDestroyArray the result of these function calls:
mxGetCell
mxGetField
mxGetFieldByNumber
But for new classdef objects, the only function you have to get the property returns a deep data copy (ugh):
mxGetProperty
So in this particular case, you do need to mxDestroyArray the result of the call (or you can rely on garbage collection to free it if you are lazy).
James Tursa
To answer your specific question regarding mxFree, it should only be used on pointers that are returned by MATLAB API functions that dynamically allocate raw memory (not mxArray variables). Those functions that work with mxFree are:
mxCalloc
mxMalloc
mxRealloc
mxArrayToString
Functions that get pointers that are part of an mxArray should *NEVER* be passed to mxFree because that would invalidate and corrupt the mxArray (a data pointer pointing to invalid memory). E.g.,
mxGetData
mxGetImagData
mxGetPr --> equivalent to (double *)mxGetData
mxGetPi --> equivalent to (double *)mxGetImagData
mxGetChars --> equivalent to (mxChar *)mxGetData
mxGetLogicals --> equivalent to (mxLogical *)mxGetData
mxGetIr
mxGetJc
mxGetFieldNameByNumber
mxGetDimensions
You can detach the data pointer from the mxArray first and *THEN* use mxFree on it, but this typically isn't done so I won't post the details here (you need to clean up the data pointer and dimensions of the mxArray etc).
Similarly, functions that get cell or struct mxArray pointers should not be destroyed with mxDestroyArray since that would invalidate the cell or struct they are part of (pointers pointing to invalid memory). This is because they get the actual pointer from the cell or struct, not a deep copy of it. So don't mxDestroyArray the result of these function calls:
mxGetCell
mxGetField
mxGetFieldByNumber
But for new classdef objects, the only function you have to get the property returns a deep data copy (ugh):
mxGetProperty
So in this particular case, you do need to mxDestroyArray the result of the call (or you can rely on garbage collection to free it if you are lazy).
James Tursa
James Tursa
Jan 24, 2014, 1:07:07 PM1/24/14
to
"James Tursa" wrote in message <lbu9c0$ran$1...@newscl01ah.mathworks.com>...
mx = mxGetCell(pm,0);
mxDestroyArray(mx); // pm is left with an invalid pointer in its data area
But this would work:
mx = mxGetCell(pm,0);
mxDestroyArray(mx); // pm at this point is invalid
mxSetCell(pm,0,NULL); // pm is now valid again
James Tursa
>
> Similarly, functions that get cell or struct mxArray pointers should not be destroyed with mxDestroyArray since that would invalidate the cell or struct they are part of (pointers pointing to invalid memory). This is because they get the actual pointer from the cell or struct, not a deep copy of it. So don't mxDestroyArray the result of these function calls:
>
> mxGetCell
> mxGetField
> mxGetFieldByNumber
I should have made the point in the above paragraph that you *CAN* mxDestroyArray the result of these calls if you also clean up the cell or struct array in the process (i.e., NULL out the entry). E.g., this by itself will cause MATLAB to eventually bomb when pm gets destroyed:
> Similarly, functions that get cell or struct mxArray pointers should not be destroyed with mxDestroyArray since that would invalidate the cell or struct they are part of (pointers pointing to invalid memory). This is because they get the actual pointer from the cell or struct, not a deep copy of it. So don't mxDestroyArray the result of these function calls:
>
> mxGetCell
> mxGetField
> mxGetFieldByNumber
mx = mxGetCell(pm,0);
mxDestroyArray(mx); // pm is left with an invalid pointer in its data area
But this would work:
mx = mxGetCell(pm,0);
mxDestroyArray(mx); // pm at this point is invalid
mxSetCell(pm,0,NULL); // pm is now valid again
James Tursa
Bruce Elliott
Jan 24, 2014, 2:04:09 PM1/24/14
to
"James Tursa" wrote in message <lbu9c0$ran$1...@newscl01ah.mathworks.com>...
> Your posts continue to drive home the point that I need to release my mex guide sooner rather than later. The MATLAB doc on this is inadequate and my mex guide adresses all of these issues.
I would pay cash for that guide!!
> < lots of very useful information snipped >
>
> James Tursa
That was all very helpful - thank you. As I've been trying to deduce what's going on behind the scenes, I've been converging on exactly the questions that you've answered.
While we all wait to see your mex guide, I'm going to print off this (and your next) post to keep handy for reference.
Bruce
Bruce Elliott
Mar 6, 2014, 9:51:10 AM3/6/14
to
> Your posts continue to drive home the point that I need to release my mex guide sooner rather than later. The MATLAB doc on this is inadequate and my mex guide adresses all of these issues.
>
> James Tursa
>
So, James Tursa - are we any closer to seeing your MEX Guide? :-)
Bruce
James Tursa
Mar 6, 2014, 11:19:10 AM3/6/14
to
"Bruce Elliott" <bruce....@jhuapl.nospam.edu> wrote in message <lfa20t$b6s$1...@newscl01ah.mathworks.com>...
OK, I will put it out in whatever state it is in this weekend with caveats ("Beta review copy" or whatever). Thanks for the prompt. (Yair has also been bugging me gently to do this as well). I keep learning new things so it keeps getting delayed, but maybe putting out a preliminary copy for review is the best thing to do at this point ...
I will point out something I did not mention in my previous posts: mxArrayToString result is *NOT* on the garbage collection list ... it must be mxFree'd manually or you will get a permanent memory leak.
James Tursa
I will point out something I did not mention in my previous posts: mxArrayToString result is *NOT* on the garbage collection list ... it must be mxFree'd manually or you will get a permanent memory leak.
James Tursa
Bruce Elliott
Mar 6, 2014, 11:55:07 AM3/6/14
to
"James Tursa" wrote in message <lfa75u$qrh$1...@newscl01ah.mathworks.com>...
Thank you!! I look forward to seeing what you've put together.
Would you be open to posting your guide on a Matlab Wiki somewhere? That would possibly be a suitable place for information like this, so that it could be updated over time as people gain new insights into the inner workings of the mx library. I've never used a Matlab Wiki, so I don't know if there is a preferred one, but the one at wikipages.org looks fairly good.
Thanks also for the note about mxArrayToString. I'm using it in some of my Mex files, just to capture filenames passed as input arguments, so if it's causing a memory leak I probably wouldn't have noticed. I'll check it out.
Bruce
Would you be open to posting your guide on a Matlab Wiki somewhere? That would possibly be a suitable place for information like this, so that it could be updated over time as people gain new insights into the inner workings of the mx library. I've never used a Matlab Wiki, so I don't know if there is a preferred one, but the one at wikipages.org looks fairly good.
Thanks also for the note about mxArrayToString. I'm using it in some of my Mex files, just to capture filenames passed as input arguments, so if it's causing a memory leak I probably wouldn't have noticed. I'll check it out.
Bruce
0 new messages