calllib crashes MATLAB, no error given.

Hi,

I am trying to call a FORTRAN .dll in MATLAB (r2018b) using the function loadlibrary and calllib. With C++ I wrote the following .h file:

#ifndef _MYMODEL
#define _MYMODEL
#ifdef __cplusplus
extern "C" {
#endif // _cplusplus

	// Functions and data types defined
	void __stdcall MYFUN(char FILEA[], char FILEB[], int *IDTask, int *nErrorCode, int *ErrorCode, double *Props, double *Out1, double *Out2, double *Out3, double *Out4, double *Out5);
#ifdef __cplusplus
}
#endif // __cplusplus

#endif // !_MYMODEL      

In MATLAB, the library is loaded with loadlibrary (no errors). However, while calling the calllib function, MATLAB crashes and does not give an error. I saw the other thread on this (exchanging cdecl for stdcall in C++; https://nl.mathworks.com/matlabcentral/answers/18313-calllib-crashes-matlab-no-error-given), however, my 'mHeader' function does not contain cdecl (and stdcall only in the commented section).

Below, my MATLAB code is included:

%% Input to model
FILEA       = 'PATH\FILEA.txt';
FILEB       = 'PATH\FILEB.txt';
IDTask      = 1;

%% Determine pointers

% input in .h file: 
lpFILEA         = libpointer('cstring', FILEA);
lpFILEB         = libpointer('cstring', FILEB);
lpIDTask        = libpointer('int32Ptr', IDTask);
lpnErrorCode    = libpointer('int32Ptr');
lpErrorCode     = libpointer('int32Ptr');
lpProps         = libpointer('doublePtr');
lpOut1          = libpointer('doublePtr');
lpOut2          = libpointer('doublePtr');
lpOut3          = libpointer('doublePtr');     
lpOut4          = libpointer('doublePtr');
lpOut5          = libpointer('doublePtr');      

%% LoadLibrary
    [notfound, warnings] = loadlibrary('MYMODEL.dll','MYMODEL.h' ,'mfilename', 'mHeader');

%% Call .dll
[~,~, ~, nErrorOut, ErrorCodeOut, PropsOut, Out1_, ~, ~, Out4_, Out5_] ...
    = calllib('MYMODEL', 'MYFUN', lpFILEA, ...
    lpFILEB, lpIDTask, lpnErrorCode, lpErrorCode, lpProps, lpOut1, ...
    lpOut2, lpOut3, lpOut4, lpOut5);

Only the first three arguments as called in calllib are input, the remainder of the variables are output.

Thanks in advance for your help!

Kind regards,

Sara

[Walter Roberson]

Which fortran compiler are you using? Are you using Intel Parallel Studio XE For Fortran? Or are you using gfortran ?

[Sara van Hoogstraten]

Hi Walter,

The .dll is already compiled (as it is external). For C++ I am using Parallel Studio.

KR, Sara

[Walter Roberson]

MATLAB supports fortran compiled with Intell Parallel Studio. If the dll happens to be compiled with gfortran then there could be a problem.

Either way the fortran run-time libraries would have to be locatable. I am having a bit of difficulty in finding the name of the fortran run-time library used by ifort (Intel Fortran compiler)

[Sara van Hoogstraten]

I asked the person that created the .dll and will get back to you on this. Regarding the second point: what is meant with the runtime library? From the organisation that provided the .dll only a .dll and a .lib file where given (?).

[Walter Roberson]

https://software.intel.com/en-us/articles/intel-compilers-redistributable-libraries-by-version

Looking at http://pleiades.ucsc.edu/doc/intel/composer_xe/14.0/compiler_f/main_for/GUID-51CE4CA9-87BF-4225-AD75-08F98D4915F7.htm I suspect it would be libifcoremt.lib that is needed, or perhaps libifcore.lib or perhaps libifcorertd.dll

[Sara van Hoogstraten]

I now downloaded both of the packages. However, in the .h file in Visual Studio, I cannot change the run-time library (as the properties window is empty). The same holds for the .dll file.

[Sara van Hoogstraten]

I just heard back from the developer: they used Microsoft Visual Studio 2015 and the Intel Fortran compiler for building the .dll.

[Chris]

While troubleshooting a similar issue, an option we did not have to pursue (solved the issue by using 2019a instead of MATLAB 2024a) was using a parallel process to run the DLL. If the DLL took a certain amount of time (in our case, 1-2 seconds was enough to know there was a problem), then the parallel process could be killed and move on. At least that was the principle. Maybe someone out there could make that a reality for their issue/workaround.

Another part of the problem was that initially my inputs exceded what the DLL could handle. So the DLL could perhaps have been coded better, but that part at least was my error.

See also

• https://www.mathworks.com/matlabcentral/answers/454098-how-to-do-wait-calllib-to-give-answer-or-catch-exception
• https://www.mathworks.com/matlabcentral/answers/18313-calllib-crashes-matlab-no-error-given
• https://www.mathworks.com/matlabcentral/answers/1580494-matlab-crashes-on-calllib