MATLAB: Do not understand mxSetData

floatsmuliple callsmxsetdata

Hi, I have declared a pointer to a float

float *myvariable;

I initialize this to

myvariable = mxCreateNumericMatrix(256,1,SINGLE (sorry for not the exact syntax),0);

Then I call a function func(myvariable);

This function does math on myvariable and returns the pointer.

Now if I have to output this variable, I get Matlab crash with this:

mxSetData(plhs[0],(float*)myvariable);

I have tried mxFree before the line but still a problem.

Questions: 1. If the second parameter is void according to definition how come my program compiles fine without error.

2. Why does Matlab crash (implying memory leak)?

3. The other option works and this is

plhs[0] = mxCreateNumericArray(256 matrix of SINGLE 0) and finally myvariable=mxGetData(plhs[0]); func(myvariable);

The reason I do not like this way is

a. I would prefer to run the function first and then assign the return to plhs[0];

b. It is a very ugly way of doing it like this, though it works.

c. I would at some point like to declare "myvariable" to be static so that every time it is requested by Matlab function some.m, I do not initialize it to 0. And I have many such variables to work with. I am updating data every fraction of a second for several minutes.

And I have to work with floats

Thanks

Best Answer

mxCreateNumericMatrix creates a Matlab variable and returns a mxArray * pointer to it. This variable has a header, e.g. the type of the values, and contains a pointer to the actual data, see mxGetPr for a DOUBLE array or mxGetData for all other types.

mxSetData injects a pointer to the data manually to the Matlab variable. This overwrites the pointer to the existing values. If you assign an mxArray pointer to the data, a crash is expected.

You have to distinguish between the Matlab arrays and their data:

float *data;
plhs[0] = mxCreateNumericMatrix(...);
data = (float *) mxGetData(plhs[0]);
func(data);

I prefer to use Matlab arrays in the main function (mexFunction) only and call all subfunctions using the C-pointers to the underlying data. Then the mexFunction is the gateway between Matlab and C and it is easy to use the subfunctions in a pure C program also.

Related Solutions

MATLAB: Return (large) unchange mxArray from MEX

plhs[0] = prhs[0] is perfectly OK in mex programming. MATLAB always (EDIT: NOT TRUE ... SEE BELOW) makes shared data copies of the plhs[ ] mxArrays and actually returns the shared data copies. To see this is true you can do this:

1) Compile this code (call it plhs_eq_prhs.c):

#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
    if( nrhs ) {
        plhs[0] = prhs[0];
        mexPrintf("The mxArray structure address of the input is %p\n",prhs[0]);
  }
}

2) Run the following commands at the MATLAB prompt:

>> format debug
>> a = 1:3
a =
Structure address = 46cdda0 
m = 1 
n = 3
pr = 16c3a440 
pi = 0
     1     2     3
>> b = plhs_eq_prhs(a)
The mxArray structure address of the input is 046CDDA0
b =
Structure address = 495aea0 
m = 1 
n = 3
pr = 16c3a440 
pi = 0
     1     2     3

You can see that the mxArray structure address of the variable b is different from the mxArray structure address of the input variable a, but the data pointers pr are the same. So MATLAB has returned a shared data copy back to the workspace.

You can get almost the same result by using the following:

   mxArray *mxCreateSharedDataCopy(mxArray *); // supply the prototype
      :
   plhs[0] = mxCreateSharedDataCopy(prhs[0]);

However, in this case there will be an extra temporary shared data copy of prhs[0] created that will be destroyed when the mex routine returns to the caller, so it is slightly less efficient that doing plhs[0] = prhs[0] directly.

The general behavior of the MATLAB API functions (the documented ones) is:

- All of the mxCreateEtc type of functions create temporary mxArrays that are put on the Variable Array List (my terminology).

- When the mex routine returns control to the caller, MATLAB makes shared data copies of the plhs[ ] variables and returns those, then everything on the Variable Array List is destroyed.

- Using mexMakeArrayPersistent removes a mxArray variable from the Variable Array List. Once a variable is removed from this list, I am unaware of any function (documented or undocumented) that will get it back on this list. So it is up to you, the programmer, to destroy it at some point in your code or you will have a permanent memory leak that can only be recovered by quitting and restarting MATLAB.

- There is a companion function mexMakeMemoryPersistent for memory allocations made with mxMalloc and friends, but in this case there is an undocumented function you can use to get it back on the garbage collection list if you want.

- There are undocumented API functions that create mxArray variables. Some of them create temporary mxArray variables that are on the Variable Array List (i.e., scheduled for garbage collection), but others create normal variables that are not on the Variable Array List. So you need to be careful when using them to avoid permanent memory leaks. mxCreateSharedDataCopy is an example of one of these undocumented API functions ... it happens to create a temporary mxArray that is on the Variable Array List (scheduled for garbage collection).

MATLAB: Mex function out plhs[0] is all zeros

There are three problems with your code.

1) Assigning the value of a pointer to another pointer does not attach the pointer to the mxArray. I.e., this line

res = result;

simply overwrites the value currently in res with the value currently in result. It does not get this value attached to plhs[0].

2) Even if you did try to attach the pointer properly to the mxArray, it wouldn't work because you can't attach native C/C++ memory (local from stack or allocated from heap with new, malloc, calloc, etc.) to an mxArray. It would either generate an error or bomb MATLAB. I.e., the proper way to attach a pointer to an mxArray is with mxSetData( ) and friends. However, in your case even this wouldn't work:

mxSetData( plhs[0], result ); // this will generate an error or bomb MATLAB

You can only attach data memory to an mxArray if it originally came from a MATLAB API function, e.g. from mxMalloc( ) and friends.

3) Even if you allocated the memory properly and got it attached properly, you will leak memory and have a mismatch in the size of the memory and the dimensions of the variable if nframes is ever anything greater than 1. You specified the dimensions as (nrows X ncols X nframes), but inside your routine you only allocate memory for (nrows X ncols) elements. Pass this back to MATLAB and the first time you try to access an element beyond the 1st frame you will access invalid memory and bomb MATLAB.

The fix for all of this is to simply pass the data pointer from the plhs[0] variable into your routine. E.g.,

#include <iostream>
#include "mex.h"
void matData(short *odata, short *h_raw, int nrows, int ncols) {
	int dim_x = nrows;
	int dim_y = ncols;
	int total_val = dim_x * dim_y;
	for (int i = 0; i < total_val; i++) {
		int idx = i;
		 odata[idx]  = h_raw[i];
	}
	return;
}
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {
    if( nrhs == 0 || !mxIsInt16(prhs[0]) ) {
        mexErrMsgTxt("Input must be int16");
    }
	short *h_raw = (short *)mxGetData(prhs[0]);
	int nrows = 1024;
	int ncols = 128;
    if( mxGetNumberOfElements(prhs[0]) < nrows * ncols ) {
        mexErrMsgTxt("Not enough elements");
    }
		
	int nframes = 1;
	int ndim = 3;
	const mwSize dims[] = { nrows, ncols, nframes };
	plhs[0] = mxCreateNumericArray(ndim, dims, mxUINT16_CLASS, mxREAL);
	
	
	short* res = (short *)mxGetData(plhs[0]);
	matData(res, h_raw, nrows, ncols);
	return;
}

Best Answer

Related Solutions

MATLAB: Return (large) unchange mxArray from MEX

MATLAB: Mex function out plhs[0] is all zeros

Related Question