problem executign mex file
1 回表示 (過去 30 日間)
古いコメントを表示
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
回答 (2 件)
Image Analyst
2013 年 9 月 28 日
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 件のコメント
Image Analyst
2013 年 9 月 28 日
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
2013 年 9 月 28 日
編集済み: Jan
2013 年 9 月 28 日
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.
Jan
2013 年 9 月 28 日
編集済み: Jan
2013 年 9 月 28 日
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.
0 件のコメント
参考
カテゴリ
Help Center および File Exchange で Debugging and Analysis についてさらに検索
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!