mxDuplicateArray( ) does indeed create deep copies ... or at least it used to. Not sure why that would have changed. There might be issues with resources in some classdef objects, but for simple classdef objects like you describe above there should be no problem with access violations or seg faults. E.g., take this code:
% myObject.m
classdef myObject
properties
data;
end
end
and
// objectdata.cpp
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
mxArray *myObjectCopy;
myObjectCopy = mxDuplicateArray( prhs[0] ); // Has a .data property
mxSetProperty(myObjectCopy, 0, "data", mxCreateDoubleScalar(4.9) );
plhs[0] = myObjectCopy;
}
Compile the mex routine:
>> mex objectdata.cpp
Building with 'MinGW64 Compiler (C++)'.
MEX completed successfully.
Run it:
>> mo = myObject
mo =
myObject with properties:
data: []
>> mo.data = 3.4
mo =
myObject with properties:
data: 3.4000
>> mr = objectdata(mo)
mr =
myObject with properties:
data: 4.9000
>> mr = objectdata(mo)
mr =
myObject with properties:
data: 4.9000
>> mr = objectdata(mo)
mr =
myObject with properties:
data: 4.9000
>> mr = objectdata(mo)
mr =
myObject with properties:
data: 4.9000
>> mr = objectdata(mo)
mr =
myObject with properties:
data: 4.9000
>> for k=1:100000; mr = objectdata(mo);end
>>
I don't have any issues with calling this mex routine repeatedly. Can you provide us with more complete code and details of your class?
I believe mxSetProperty( ) takes care of destroying the current data property in the background so that you don't have a memory leak, although this is not documented. E.g., as evidence, this doesn't run out of memory:
>> mo.data = rand(1,100000000);
>> for k=1:10000000; mr = objectdata(mo);end
>>
Note that this is different behavior from mxSetCell( ) for cell arrays and mxSetField( ) for struct arrays, where you would get a memory leak if you did not manually properly destroy the existing cell or field element first.
*** EDIT #1 ***
So, I put in some memory prints surrounding the mxDuplicateArray( ) calls and got something unexpected, at least to me:
// objectdata2.cpp
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
mxArray *myObjectCopy;
mexPrintf("\n\nBefore mxDuplicateArray call ...\n\n");
mexCallMATLAB(0,NULL,0,NULL,"memory");
myObjectCopy = mxDuplicateArray( prhs[0] ); // Has a .data property
mexPrintf("\n\nAfter mxDuplicateArray call ...\n\n");
mexCallMATLAB(0,NULL,0,NULL,"memory");
mxSetProperty(myObjectCopy, 0, "data", mxCreateDoubleScalar(4.9) );
plhs[0] = myObjectCopy;
}
Running:
>> mo = myObject
mo =
myObject with properties:
data: []
>> mo.data = rand(1,100000000);
>> mr = objectdata2(mo)
Before mxDuplicateArray call ...
Maximum possible array: 3338 MB (3.500e+09 bytes) *
Memory available for all arrays: 3338 MB (3.500e+09 bytes) *
Memory used by MATLAB: 3160 MB (3.313e+09 bytes)
Physical Memory (RAM): 16073 MB (1.685e+10 bytes)
* Limited by System Memory (physical + swap file) available.
After mxDuplicateArray call ...
Maximum possible array: 3339 MB (3.501e+09 bytes) *
Memory available for all arrays: 3339 MB (3.501e+09 bytes) *
Memory used by MATLAB: 3160 MB (3.313e+09 bytes)
Physical Memory (RAM): 16073 MB (1.685e+10 bytes)
* Limited by System Memory (physical + swap file) available.
mr =
myObject with properties:
data: 4.9000
The memory footprint did not go up when mxDuplicateArray( ) was called, even though the data property is 763MB and should be easy to see. I may have to retract what I said about mxDuplicateArray( ) when dealing with classdef objects. These don't look like deep copies to me now. Because you don't have direct access to the properties, maybe MATLAB is in fact doing shared data copies behind the scenes.
That being said, I still don't know why you would be getting seg faults. It would help if you posted a small complete example that demonstrates the problem.
*** EDIT #2 ***
To confirm this:
// mxDuplicateArray.c
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
plhs[0] = mxDuplicateArray( prhs[0] ); // Has a .data property
}
and
// datapointers.c
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
mexPrintf("pr = %p\n",mxGetData(prhs[0]));
}
gives this:
>> mo = myObject
mo =
myObject with properties:
data: []
>> mo.data = rand(1,100000000);
>> mr = mxDuplicateArray(mo)
mr =
myObject with properties:
data: [1×100000000 double]
>> datapointers(mo.data)
pr = 000002E1FF6DF060
>> datapointers(mr.data)
pr = 000002E1FF6DF060
So, yes, it is confirmed that mxDuplicateArray( ) does a shared data copy in the background when working with classdef objects (same data pointer). Surprising to me, but there it is.
