I have two condition:
- new = myfunc(origin)
- origin = myfunc(origin)
Can I get the name of variable such as "new" and "origin" in mex file?
MATLAB: Can I check that is the output variable same as input variable in mex
mexnameoutput
Related Solutions
The reason this crashes is because you have created a copy of an mxArray variable without telling the MATLAB Memory Manager that you did so. So when MATLAB subsequently clears one of these it invalidates the other, and then when MATLAB tries to use or clear the other it accesses invalid memory and crashes. I.e.,
plhs[0]= mxGetField(prhs[0],0,"b"); The above gets the the mxArray pointer from prhs[0] and assigns this exact pointer to plhs[0] ... essentially a reference copy. So now there is an extra reference copy of prhs[0] in the system but the MATLAB Memory Manager doesn't know about it. Eventually downstream in your code all of these copies get cleared, but on the next to last one MATLAB thinks all the copies are cleared so it releases the memory. Then when it tries to use or clear the last one it accesses invalid memory and crashes.
The same thing would happen if you tried to copy an mxArray pointer from one cell or struct array element into another element, either in the same or a different cell or struct array. This would in essence create a reference copy of the variable without telling the MATLAB Memory Manager about it. MATLAB will crash downstream at some point when these variables are cleared. This practice could be done safely if you were to bump up the reference count of the variable each time you made a new assignment, but this requires mxArray hacks because there is no API function to do this.
There are three ways to extract an mxArray variable from a cell or struct variable and assign it to a plhs[ ] variable. Assuming you have already checked that nrhs >= 1 and that mxGetField(prhs[0],0,"b") is not NULL:
1) The only official way, which creates a deep copy:
plhs[0] = mxDuplicateArray(mxGetField(prhs[0],0,"b"));This is the only method that is officially supported and will likely not break in the future. The downside is that if you are working with very large variables it can be a tremendous waste of time and memory to create this deep copy.
2) Using an unofficial API function to create a shared data copy:
plhs[0] = mxCreateSharedDataCopy(mxGetField(prhs[0],0,"b"));This method is very fast and is useful for large variables. But this method requires you to jump through some hoops, and it may break in the future if they remove this function from the API library. Details for using it can be found in the header file here:
3) Bump up the reference count:
plhs[0] = mxCreateReference(mxGetField(prhs[0],0,"b"));This method is also very fast and useful for large variables. This function used to be in the API library, and the only thing needed to use it was a prototype. However, this function was removed from the API library back in R2014a. So the only way to do this now is to hack into the mxArray itself. This is tricky to do since the mxArray definition and the location of the reference count field has changed over the years. Also the rules for how MATLAB handles the plhs[ ] variables are not published so it is unclear if this will even work for a sub-array type variable instead of a temporary variable. Although this would be the obvious method to use when copying cell or struct field variables from one cell or struct array to another cell or struct array, I wouldn't advise this option for assigning to the plhs[ ] array variables. I would advise method 2 instead for plhs[ ] array variable assignment.
Note that MATLAB itself generally uses either method 2 or 3 in the background when you are working at the m-file level, but for some reason has not made these methods official for mex programmers.
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:3a =Structure address = 46cdda0 m = 1 n = 3pr = 16c3a440 pi = 0 1 2 3>> b = plhs_eq_prhs(a)The mxArray structure address of the input is 046CDDA0b =Structure address = 495aea0 m = 1 n = 3pr = 16c3a440 pi = 0 1 2 3You 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).
Best Answer