I have been confused by a very strange mex error just now . . .
Boiling my problem right down to its core, we end up with the following simple mex code. It just displays if given structure fields are empty or not ...
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
int numElements = mxGetNumberOfElements(prhs[0]);
int numFields = mxGetNumberOfFields(prhs[0]);
mxArray* tmpData;
const char* tmpName;
for (int structIdx=0; structIdx<numElements; ++structIdx)
{
for (int fieldIdx=0; fieldIdx<numFields; ++fieldIdx)
{
tmpData = mxGetFieldByNumber(prhs[0], structIdx, fieldIdx);
tmpName = mxGetFieldNameByNumber(prhs[0], fieldIdx);
if (mxIsEmpty(tmpData))
mexPrintf("struct(%i).%s is empty\n", structIdx+1, tmpName );
else
mexPrintf("struct(%i).%s contains data\n", structIdx+1, tmpName );
}
}
}
If we compile this code and call it structcrash then the following matlab code . .
clc
x.a=1;
x.b=2;
x(2).a=3;
x(2).b=4;
structcrash(x);
...gives the output we might expect...
- struct(1).a contains data
- struct(1).b contains data
- struct(2).a contains data
- struct(2).b contains data
If we give the mex function a structure containing an empty field like so...
clc
y.a = [];
structcrash(y);
... then we also get the expected output ...
- struct(1).a is empty
Now, things get very strange if you use code like this ...
clc
y(2).b = 4;
structcrash(y);
If we inspect the y structure, is is now a 2 element structure with 2 fields in each element. y(1).a is empty as we specified above, and y(1).b has been automatically created and given an empty value when we added the b field. Similarly, y(2).a was automatically created when we increased the structure size by adding y(2).b. The structure looks perfectly logical, however using as an input to the mex file results in a segfault.
By selectively commenting-out various lines of code, I can confirm that the command that causes the segfault is mxIsEmpty(tmpData).
Can anyone else replicate this error and am I doing something fundamentally wrong here? It looks like a bug in the mex API code to me, but I wanted to check here first. Thanks
EDIT: Based on @David Heffernan's advice I modified the code as follows
if(tmpData!=NULL) {
if (mxIsEmpty(tmpData))
mexPrintf("struct(%i).%s is empty\n", structIdx+1, tmpName );
else
mexPrintf("struct(%i).%s contains data\n", structIdx+1, tmpName );
}
...and the segfault no longer occurs. However, this is still very ominous. If you create two structures like in the following example and examine them using the workspace view, f and g look absolutely identical in every way. I cannot find any way in which they differ using standard matlab programming commands.
>> f(2).a=123;
>> g(1).a=[];
>> g(2).a=123
... but the whos command reveals a difference ...
Name Size Bytes Class Attributes
f 1x2 192 struct
g 1x2 296 struct
... and my updated mex function obviously does too ...
>>structcrash(f)
struct(2).a contains data
>> structcrash(g)
struct(1).a is empty
struct(2).a contains data
So the moral of this story is that the Matlab IDE makes structs look nice and square by inserting fields in all structs when you insert a new field into a particular struct element. However, in reality, in the underlying memory, this is not the case.