What happens when Matlab exits C-Mex program after a pointer was overridden

Hi,

1. Inside C-Mex file, Suppose I use mxcalloc to allocate dynamic memory. The pointer to the allocated memory is returned to pA. Now I override pA, so pA no longer holds the address to the allocated memory (I know it can cause a memory leak, but that is not the point). When C-Mex function exits, as I understand, it automatically frees all dynamic memory made by mxcalloc, mxmalloc, mxrealloc. Does it need pA to hold the dynamic allocated address in order to free the memory at exit or it doesn't matter what value pA hold ?

2. Same question when I use mxCreate*: Suppose I use mxCreateDoubleMatrix. The pointer to the allocated memory is returned to pA. Now I override pA, so pA no longer holds the address to the allocated memory (suppose I don't use mxDestroyArray). When C-Mex function exits, does it free all associated mxarray elements of pA? does it need pA to hold the pointer address in order to free the memory at exit or it doesn't matter what value pA hold ?

3. mxDestroyArray - in the help it says one should free any variable created with mxCreate* with mxDestroyArray, but only if the variable is not returned to the left hand side. Does the following line means pA is return to the left hand side: "mxSetCell(plhs[0],0,pA)" ? can I add this line after the previous one: "mxDestroyArray(pA)" ?

Answer 1

[James Tursa]

1. It doesn't matter what value pA holds when the mex file exits. These addresses are being kept track of by the MATLAB Memory Manager garbage collection separately. The memory will get free'd regardless of the value of pA.

2. Same answer, but slightly different. The address of the mxArray is held by the MATLAB Memory Manager garbage collection separately. It doesn't matter if you have a variable with this value or not. The mxArray will get destroyed when the mex file exits. The data memory (i.e., the memory behind the addresses returned by mxGetPr, mxGetPi, etc) is NOT held by the MATLAB Memory Manager garbage collection separately. In order for it to get free'd it needs to remain attached to an mxArray (which should normally be the case unless you have manually manipulated the data pointers for some reason). .

3. The line mxSetCell(plhs[0],0,pA) sets the cell element address at the 0'th index of plhs[0] to the value contained in pA. Then the address contained in pA is removed from the MATLAB Memory Manager garbage collection list (its disposition now being dependent on its parent, plhs[0]) and the variable type is changed to "Sub-Element". If you subsequently issue the line mxDestroyArray(pA) you will cause a MATLAB crash at some point downstream because the mxArray sitting at the 0'th index of plhs[0] is no longer pointing to valid memory. At some point downstream you will attempt to access it and that will crash MATLAB. Once you make an mxArray part of a cell or struct array, do not use mxDestroyArray on it. This is true for all cell and struct arrays, btw, not just ones that happen to be a plhs[0] variable. Note the different behavior of mxSetCell (and mxSetField etc) to mxSetProperty. mxSetCell places the actual address of pA into the cell array, whereas mxSetProperty would place a deep copy of pA into the class object.

[Abe]

Thanks, Your answers has been helpful to me. About answer 3: "mxSetCell places the actual address of pA into the cell array" - I didn't see any mention of it in Matlab help. I have encountered few times with lack of information at Matlab help. How did you find this information ?

[James Tursa]

You can use mxGetData on the cell array to recover a pointer to all the mxArray addresses it has for data (i.e., the cell elements). If you examine them you will find the address contained in pA to be the first data item of the cell array. Thus, the actual mxArray address was put there, not an address of a copy.

MATLAB used to publish some of the details of the mxArray header structure. That, plus some sleuthing on my part, has allowed me to discover how the API functions work for these kinds of details that are not mentioned in the doc.

[Abe]

Thanks