I have MATLAB mex code that hacks into the mxArray header to read and modify fields such as the CrossLink pointer (used for shared data copies) etc. This is necessary to allow me to work with very large variables inside mex routines without creating deep copies. This code works well up to R2018b but now crashes MATLAB. What has changed?
The mxArray header has changed in R2019a. The location of the CrossLink field in the mxArray header has moved next to the reverse CrossLink field. So, the order for R2018b and earlier is this:
void *RevCrossLink;
mxClassID ClassID;
int VariableType;
mxArray *CrossLink;
:
etc.
but for R2019a it is this
void *RevCrossLink;
mxArray *CrossLink; <-- moved
mxClassID ClassID;
int VariableType;
:
etc.
So if you want your code to be robust and compile/run under different MATLAB versions, you will need to programmatically determine the MATLAB version. C code to determine the MATLAB version at compile and run time can be found here:
https://www.mathworks.com/matlabcentral/fileexchange/67016-c-mex-matlab-version
Related
I started working with Matlab production libraries: Matlab Coder and Matlab library Compiler. I have several questions
What is the difference between mxArray and mwArray? (answer below)
Is it possible to set mxArray with user predefined data? (answer below)
3. Is it possible to set mwArray with user predefined data?
4. Is it possible to run Matlab library compiler DLL from mex file?
I combined a matlab library compiler dll with matlab coder using
coder.ceval(...)
The first call to either
mlcInitializeApplication(..)
or
MY_MATLAB_LIBRARY_NAME_Initialize(..)
return false and any mwArray constructor throws an exception
Is there a problem mixing mex and mlc runtime libraries?
** btw - when I compiled the mex code to C++ everything worked.
What is the difference between mxArray and mwArray?
(From Matlab) mwArray is a class (C++ concept) used to pass input and output to C++ function generated by Matlab compiler SDK
This class consists of a thin wrapper around a MATLAB® array. All data in MATLAB is represented by arrays. The mwArray class provides the necessary constructors, methods, and operators for array creation and initialization, as well as simple indexing
mxArray is a C type that hold an opaque type. It can hold arrays or matrices mainly as input / output for C mex files.
** I guess that the mx initiative comes for mex and the mw initiative comes for matlab wrapper, but I'm not sure about it.
Is it possible to set mxArray with user predefined data - yes
Here is an example
mxArray *output[];
output[0] = mxCreateNumericArray(ndim, dim, mxDOUBLE_CLASS, mxREAL);
outData = mxGetPr(yourPtr);
3. Is it possible to set mwArray with user predefined data? I don't know
Is it possible to run Matlab library compiler DLL from mex file?
From Matlab engineer: It's not possible to mix mlc and mex runtimes.
I'm trying to convert my image processing code on MATLAB into C by using MATLAB coder. using imread needs a coder.entrinsic declaration. However, this means that the output to imread will be an mxArray. This is a problem as I cannot use this with the step function. The error report from code generation is shown below:
Does anyone know a way around this?
When using coder.extrinsic, functions declared as extrinsic will return mxArray types. If you pass these to other Matlab functions, Coder will resolve everything well, but if you use them with your own functions or in any way try to manipulate them, you need to help Coder resolve them into a known type. You do this by pre-defining a variable and copying the mxArray into it, which will allow Coder to correctly convert to a standard data type. If you know the exact size beforehand, you can preallocate the variable before the call and skip the copy, but in this case it may be a bit trickier.
In the case of your function, I assume you have a call somewhere that looks like:
I = imread([some paramaters]);
We need to get the mxArray type from the call to imread, then determine its dimensions so that another variable can be allocated in a native type. The determination of the mxArray dimensions using the size function itself needs to have a preallocated variable so that size does not return a mxArray also. Here are the steps:
coder.extrinsic('imread');
Itemp = imread([some paramaters]);
idims = zeros(1,3); %Need to preallocate idims so it does not become an mxArray
idims = size(Itemp)
I = coder.nullcopy(zeros(idims, 'uint8')); % Allocate but do not initialize an array of uint8 values of the same size as Itemp
I = Itemp; % Copy the data from the mxArray into the final variable.
If you know the exact size of the image before the call to imread, you can skip the copy and the second variable and simply preallocate the variable I to the correct size, but this is not typically the case for an image read.
You can see a little more information on how to do this in the following help document from Mathworks:
http://www.mathworks.com/help/simulink/ug/calling-matlab-functions.html#bq1h2z9-47
A question about Matlab and C function (I'm not expert in Matlab):
I have a working matlab code (downloaded from internet) which calls
a function 'foo':
[output] = foo(input)
Now, this function 'foo' is defined inside a 'C' file (foo.c), which was then compiled as a library for Matlab (foo.mexa64).
Looking at foo.c, I can see there are two functions:
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
void foo(double* out, double* in);
As I understand, the mexFunction() allocates pointers for input and outputs, and fill them with proper data from Matlab code.
My question is: if Matlab calls foo several times, is mexFunction() called everytime or it is called just the first time?
It is called every time foo is called; the inputs of the MEX function are in general different, therefore, the desired outputs need to be re-computed by the MEX function.
mexFunction is called very time the MATLAB-foo is called.
That's just how the mex-interface works:
You give MATLAB a mex-file and MATLAB just calls the mexFunction out of this library, everytime you invoke the function.
Basically, MATLAB doesn't care about anything else in your library.
If you'd like to call only the C-version of foo, you might want to look into the documentation of loadlibrary and the referenced function therein.
I'm using the mxCreateNumericMatrix function at my mex file:
mxArray *mxCreateNumericMatrix(mwSize m, mwSize n, mxClassID classid, mxComplexity ComplexFlag);
I want to get array of type mwSize.
For that I need to determine if using mxUINT32_CLASS or mxUINT64_CLASS as classid.
I can determine it in runtime with if statement on sizeof(mwSize), but is there a more elegant way to determine the class ID of mwSize? Maybe some define that depends on the system which has one value or the other?
Just a matter of aesthetics.
BTW, at Fortran there is a function mxClassIDFromClassName:
http://www.mathworks.com/help/matlab/apiref/mxclassidfromclassname.html
mwSize is used for among the other reasons, so that the mxCreateDoubleMatrix function will be portable. It is strange if no elegant solution exists for mxCreateNumericMatrix.
Edit:
As #Praetorian explained, in my case I have no reason to use the type that fits the system (32 or 64 bits), as I specifically prefer it to be 64-bit integer array, and I can define this size also in 32-bit system.
But on the other hand, I also want to return two indices to the array that I return. In my case, I know that the array itself is short, and I use uint16_T anyway, but if I wanted it to fit the mwIndex, I would have to use some macro (#Amro suggested some good options), because apparently, there is no function as mxCreateDoubleMatrix for integers (that fits the system).
To sum it up, #Praetorian helped me with my case in the comments below and #Amro gave probably the best options available for the general case.
The goal of mxCreateNumericMatrix and other mxCreate* functions is to create an mxArray (MATLAB fundamental type). Such arrays can be returned to MATLAB from the MEX-function.
mwSize is just a typedef to a size_t type (might be different for 32-bit vs. 64-bit), which is not a valid MATLAB datatype (not part of mxClassID). If actually you want to create an array of mwSize, allocate memory in C the usual way mxMalloc (but I doubt this is what you want in this case).
As Praetorian notes, the actual C type to which mwSize and mwIndex are typedef'ed is determined by the flags you pass to the mex command (or the default value if you didnt explicitly specify one):
>> mex -largeArrayDims file.c
>> mex -compatibleArrayDims file.c
If we inspect the tmwtypes.h header file which gets included, here is the relevant block of code:
#ifdef MX_COMPAT_32
typedef int mwSize;
typedef int mwIndex;
typedef int mwSignedIndex;
#else
typedef size_t mwSize; /* unsigned pointer-width integer */
typedef size_t mwIndex; /* unsigned pointer-width integer */
typedef ptrdiff_t mwSignedIndex; /* a signed pointer-width integer */
#endif
(Recall that size_t is itself platform-dependent).
As mentioned in the comments above, I think you are misinterpreting the documentation. mwIndex and mwSize are meant to be used when indexing into a matrix and when dealing with matrix sizes respectively when writing MEX-function (instead of using non-portable plain int). They do not have corresponding mxClassID (so you cannot create mxArray's of those types and pass them back to MATLAB).
Now if you want to create an array of indices and return it to MATLAB to be used as a regular variable, you could create an mxArray of the equivalent type to unsigned integers (matching the bit-ness of your architecture: 32-bit vs 64-bit). Use macros to determine which one you are compiling for, and use mxUINT32_CLASS or mxUINT64_CLASS accordingly.
For example, we could use the same macro MATLAB is using:
#ifdef MX_COMPAT_32
typedef mxUINT32_CLASS INDICES_CLASS;
#else
typedef mxUINT64_CLASS INDICES_CLASS;
#endif
mxArray *arr = mxCreateNumericMatrix(10, 1, INDICES_CLASS, mxReal);
// ... fill arr with indices
Have you tried mxClassIDFromClassName in C? According to this list of undocumented libmx functions discussed here, it seems to exist. But yes, if you want to stick to what is listed in the online documentation, I don't know of a way other than using an if statement. Creating things other than double matrices in mex is always messier.
I have been trying to figure this out for quite some time.
I use a MEX file in matlab (Linux 64bit) which uses CUDA. The code compiles and executes fine but when I want to unload the mex (e.g. to recompile it or when matlab exits), matlab crashes immediately without any message and with an empty dump.
I was able reduce it to a minimal working example:
MEX cpp File:
#include <stdint.h>
#include "mex.h"
extern "C" void cudaTest();
void mexFunction(
int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[])
{
cudaTest();
}
CUDA File compiled with NVCC:
void cudaTest() {
float* d_test = NULL;
cudaMalloc((void**) &d_test, 10000 * sizeof(float));
cudaFree(d_test);
}
While with my real program it always crashes, with this minimal example it is not always reproducible. Sometimes it does crash sometimes not..
I think this solved my problem:
http://www.mathworks.de/matlabcentral/answers/45307
Hmm, It may be memory problem which your forgot to free.
Some suggestions might useful:
Don't use MATLAB memory management function: mxalloc..., outside mexfunction or matlab wrap, your mex function might run some process background and might cause MATLAB crash, when mex function call memory management function simultaneously with matlab.
register mexAtExit(clearfunction) function(see MATLAB help: mexAtExit) clear your mex memory and thread which is not managed by MATLAB aotumaticly, i.e. cudaMalloc here. when mex function unload or matlab exit, MATLAB would automaticly clear mexfunction. so if your momery management function is not MATLAB memory management function, MATLAB wouldn't know how to deal with your mex program.
debug your function as below
run:
clear your_mex_function
MATLAB would call clearfunction(this function is a mexatexit register function see upside step) of your_mex_function, and you will find out what's the problem of your mex function.