problem executign mex file

1 view (last 30 days)
michael
michael on 28 Sep 2013
Commented: Jan on 30 Sep 2013
Hello,
I've wrote some mex file, compiled it without any problem, but have problem to run it. Every time when I'm executing it, I'm getting an some internal matlab error and that i need to close matlab.
Can somebody go over the code and find the source of the problem? (I guess it is in the return parameters)
BR
  3 Comments
Kaustubha Govind
Kaustubha Govind on 30 Sep 2013
You might want to debug your MEX-file and isolate the line numbers causing the crash.
Jan
Jan on 30 Sep 2013
@michael: Did you see my question?

Sign in to comment.

Answers (2)

Image Analyst
Image Analyst on 28 Sep 2013
Anytime you get that error, where the whole of MATLAB comes crashing down in a fiery mess, you need to call the Mathworks. Even if there were a problem with your code, it shouldn't bring the whole MATLAB program down.
  3 Comments
Image Analyst
Image Analyst on 28 Sep 2013
Their program should handle it gracefully. You're running the mex file from MATLAB - from an m-file - right? Not from some other program. I can see no circumstances where it would be acceptable for their whole program (MATLAB) to shutdown rather than just your m-file. If your program causes problems in Microsoft Visual Studio, you don't see Visual Studio come crashing down, do you? Of course not, so neither should MATLAB.
Jan
Jan on 28 Sep 2013
Edited: Jan on 28 Sep 2013
No, I do not agree. You can easily confuse the memory manager in a MEX file, e.g. by writing to X[4], when the array X has less elements. Therefore it is very easy to let Matlab crash from inside a MEX function, even to an arbitrary later time. Example:
plhs[0] = mxCreateDoubleMatrix(1, 5, mxREAL);
mxSetData(plhs[0], malloc(5 * sizeof(double));
This leaks memory and let Matlab crash, when the replied variable is cleared from the memory.

Sign in to comment.


Jan
Jan on 28 Sep 2013
Edited: Jan on 28 Sep 2013
This should cause severe problems:
output_data_len = (int) mxGetData(prhs[2]);
mxGetData replies a void * pointer and converting it to int will produce different results on a 32 and 64 bit machine. But in both cases you get the pointer to the data, not the value of the first element. Perhaps you mean:
output_data_len = (int) mxGetScalar(prhs[2]);
You use output_data_len here:
decision = (double*) malloc(output_data_len * sizeof(double))
But if output_data_len is the address, this should reply a NULL pointer. Better use mxMalloc, which care for such problems, or (better and) check the replied pointer.
Finally, this will confuse Matlab's memory manager massively:
plhs[0] = mxCreateDoubleMatrix(1, output_data_len, mxREAL);
mxSetData(plhs[0], decision);
On one hand mxCreateDoubleMatrix allocates memory for the data already. mxSetData overwrites the pointer to these data, such that the memory is leaked. Then the memory for the data in plhs[0] has been created by malloc, but inside Matlab it is released by mxFree. This must crash Matlab's memory manager.
I guess, you want something like:
output_data_len = (mwSize) mxGetScalar(prhs[2]);
plhs[0] = mxCreateDoubleMatrix(1, output_data_len, mxREAL);
decision = mxGetPr(plhs[0]);
Equivalent changes are required for all other "(int) mxGetData" calls.

Categories

Find more on Debugging and Analysis in Help Center and File Exchange

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!