Compiled Matlab code crashes when /clr is not selected

2 views (last 30 days)
I'm wondering why the code I'm using with a compiled Matlab library crashes when a common language runtime is not selected. For a minimal example, I've tried compiling the following Matlab function into a shared library:
function [volOut, volAvg]=testVarPass(volIn)
volOut=double(volIn);
volAvg=mean(volOut(:));
end
using the following call to mcc: mcc -B csharedlib:mylib testVarPass.m
Next, I've set up a Visual Studios 2010 Console Project.
#include "stdafx.h"
#include "matrix.h"
#include "mylib.h"
int _tmain(int argc, _TCHAR* argv[])
{
mxArray *vol_in;
mxArray *vol_out;
mxArray *vol_avg;
mwSize dim_list[3];
double *vol_avg_ptr;
dim_list[0]=10;
dim_list[1]=10;
dim_list[2]=10;
if( !mclInitializeApplication(NULL,0) ) { //initialize Matlab Compiler Runtime
return -1;
}
if (!mylibInitialize()) //initialize library
{
return -2;
}
vol_in=mxCreateNumericArray(3,dim_list, mxINT16_CLASS, mxREAL); //make a sample 3d array
mlfTestVarPass(2, &vol_out, &vol_avg, vol_in); //crashes here
vol_avg_ptr=mxGetPr(vol_avg);
/* Call the MCR and library termination functions */
mylibTerminate();
mclTerminateApplication();
return 0;
}
If I build the project with Common Language Runtime Support set to: /clr...everything works fine. If I build the project with Common Language Runtime Support set to: nothing...first, the debugger vomits many exceptions when mylibInitialize is called. The most common are: varflowFailed, tffFailed, CryptoPP, jitCgFailed, and xsd_binder::MalformedDocumentError. Second, the mlfTestVarPass call crashes with an access violation.
I, and a programmer I'm working with, are wondering why.
Other Information: Windows 7 Visual Studio 2010, SP1 Windows SDK 7.1 Matlab 2013b
  1 Comment
JohnL
JohnL on 15 Mar 2016
I had the same problem. I had the "Debug Un-managed Code" box checked in the CLR project. Unchecking that made the debugger ignore the plethora of Matlab exceptions and things ran normally. But you gotta wonder, who writes code that "normally" generates that many exceptions?

Sign in to comment.

Accepted Answer

Harsheel
Harsheel on 25 Apr 2014
mlf* functions "always" free the memory that is pointed to by the output mxArray* before overwriting the memory with the new value that was just returned by the compiled MATLAB code. This is documented on pg 13-30 here:
As the doc says, the output mxArray* should be set to NULL. /clr just does that. As far as the 'First Chance Exceptions (FCE)' are concerned, they are expected in Debug mode. /clr means /Eha which hides all exceptions thrown by the "throw" statement thereby hiding the FCE. Note that FCE does not necessarily mean an error in the code. So in essence, in your code, you need to initialize vol_out and _vol_avg to NULL.

More Answers (0)

Categories

Find more on MATLAB Compiler in Help Center and File Exchange

Products

Community Treasure Hunt

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

Start Hunting!