Why did Matlab crash when I run mexw64 file ?

Hello to all,

I spent some time transforming my Fortran files to mexw64 file by using Mex function,

but unfortunately, when I call this mexw64 function in Matlab ,it crashed. However, I have

sucessfully run my Fortran code in VS. That confused a lot. Can someone help me with this?

Here is the stack trace:

MATLAB crash file:C:\Users\70489\AppData\Local\Temp\matlab_crash_dump.31664-1:


------------------------------------------------------------------------
           Stack overflow detected at Mon Nov 09 15:47:55 2020
------------------------------------------------------------------------

Configuration:
  Crash Decoding      : Disabled - No sandbox or build area path
  Crash Mode          : continue (default)
  Current Graphics Driver: Unknown hardware 
  Default Encoding    : GBK
  Deployed            : false
  Graphics card 1     : NVIDIA ( 0x10de ) NVIDIA GeForce GTX 950M Version 23.21.13.9077
  Graphics card 2     : Intel Corporation ( 0x8086 ) Intel(R) HD Graphics 4600 Version 20.19.15.4549
  Host Name           : DESKTOP-BATKBTU
  MATLAB Architecture : win64
  MATLAB Entitlement ID: 123
  MATLAB Root         : F:\Matlab 2017a
  MATLAB Version      : 9.2.0.538062 (R2017a)
  OpenGL              : hardware
  Operating System    : Microsoft Windows 10 家庭中文版
  Processor ID        : x86 Family 6 Model 60 Stepping 3, GenuineIntel
  Virtual Machine     : Java 1.7.0_60-b19 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
  Window System       : Version 10.0 (Build 18362)

Fault Count: 1


Abnormal termination:
Stack overflow

Register State (from fault):
  RAX = 000000000eafcad8  RBX = 0000000000000000
  RCX = 00007ffc529d3b50  RDX = 00007ffc529d3ac0
  RSP = 00000000043fb210  RBP = 0000000000000002
  RSI = 0000000000000002  RDI = 0000000000000012
 
   R8 = 00000000043fb2b8   R9 = 0000000000000000
  R10 = 0000000000000000  R11 = 0000000000403000
  R12 = 0000000000000012  R13 = 00000000043fc1f8
  R14 = 00000000043fc1f0  R15 = 00000000043fc2d0
 
  RIP = 00007ffc529bea97  EFL = 00010287
 
   CS = 0033   FS = 0053   GS = 002b

Stack Trace (from fault):
[  0] 0x00007ffc529bea97 C:\Users\70489\Desktop\Work\columnshell\src\sp3max.mexw64+00846487 LES+00841831
[  1] 0x00007ffc528f1246 C:\Users\70489\Desktop\Work\columnshell\src\sp3max.mexw64+00004678 LES+00000022
[  2] 0x00007ffc528f1168 C:\Users\70489\Desktop\Work\columnshell\src\sp3max.mexw64+00004456 MEXFUNCTION+00000360
[  3] 0x00000000fc5fd8a4                               bin\win64\libmex.dll+00120996 mexRunMexFile+00000276
[  4] 0x00000000fc5fc4f2                               bin\win64\libmex.dll+00115954 mexFeature_mexver+00002130
[  5] 0x00000000fc5fb306                               bin\win64\libmex.dll+00111366 mexUnlock+00023430
[  6] 0x0000000015ac44d4                     bin\win64\pgo\m_dispatcher.dll+00017620 Mfh_file::dispatch_fh_impl+00000820
[  7] 0x0000000015ac4196                     bin\win64\pgo\m_dispatcher.dll+00016790 Mfh_file::dispatch_fh+00000062
[  8] 0x0000000015ac98fd                     bin\win64\pgo\m_dispatcher.dll+00039165 Mfunction_handle::dispatch+00001037
[  9] 0x00000000167baadd                            bin\win64\pgo\m_lxe.dll+00240349
[ 10] 0x00000000167a26c9                            bin\win64\pgo\m_lxe.dll+00141001
[ 11] 0x00000000167a32f3                            bin\win64\pgo\m_lxe.dll+00144115
[ 12] 0x00000000167a474c                            bin\win64\pgo\m_lxe.dll+00149324
[ 13] 0x00000000167a5288                            bin\win64\pgo\m_lxe.dll+00152200
[ 14] 0x00000000167a498f                            bin\win64\pgo\m_lxe.dll+00149903
[ 15] 0x0000000016798c4b                            bin\win64\pgo\m_lxe.dll+00101451
[ 16] 0x00000000167a004a                            bin\win64\pgo\m_lxe.dll+00131146
[ 17] 0x000000001679f7d0                            bin\win64\pgo\m_lxe.dll+00128976
[ 18] 0x00000000168f5d0f                            bin\win64\pgo\m_lxe.dll+01531151 boost::archive::detail::iserializer<boost::archive::binaryTerm_iarchive,std::vector<MathWorks::lxe::MatlabIrTree * __ptr64,std::allocator<MathWorks::lxe::MatlabIrTree * __ptr64> > >::load_object_data+00028959
[ 19] 0x00000000168f52d3                            bin\win64\pgo\m_lxe.dll+01528531 boost::archive::detail::iserializer<boost::archive::binaryTerm_iarchive,std::vector<MathWorks::lxe::MatlabIrTree * __ptr64,std::allocator<MathWorks::lxe::MatlabIrTree * __ptr64> > >::load_object_data+00026339
[ 20] 0x00000000168f51b9                            bin\win64\pgo\m_lxe.dll+01528249 boost::archive::detail::iserializer<boost::archive::binaryTerm_iarchive,std::vector<MathWorks::lxe::MatlabIrTree * __ptr64,std::allocator<MathWorks::lxe::MatlabIrTree * __ptr64> > >::load_object_data+00026057
[ 21] 0x0000000016980ea9                            bin\win64\pgo\m_lxe.dll+02100905 boost::archive::detail::iserializer<boost::archive::binaryTerm_iarchive,MathWorks::lxe::MatlabIrTree>::load_object_data+00015609
[ 22] 0x0000000016980e32                            bin\win64\pgo\m_lxe.dll+02100786 boost::archive::detail::iserializer<boost::archive::binaryTerm_iarchive,MathWorks::lxe::MatlabIrTree>::load_object_data+00015490
[ 23] 0x00000000168f30dd                            bin\win64\pgo\m_lxe.dll+01519837 boost::archive::detail::iserializer<boost::archive::binaryTerm_iarchive,std::vector<MathWorks::lxe::MatlabIrTree * __ptr64,std::allocator<MathWorks::lxe::MatlabIrTree * __ptr64> > >::load_object_data+00017645
[ 24] 0x0000000015dad0cb                    bin\win64\pgo\m_interpreter.dll+00446667 inEvalCmdWithLocalReturn+00000063
[ 25] 0x00000000fb60923d                          bin\win64\libmwbridge.dll+00102973 mnGetPrompt+00013165
[ 26] 0x00000000fb60a2f3                          bin\win64\libmwbridge.dll+00107251 mnParser+00001107
[ 27] 0x00000000159175f1                                  bin\win64\mcr.dll+00226801 mcr::runtime::setInterpreterThreadSingletonToCurrent+00027889
[ 28] 0x00000000159164e7                                  bin\win64\mcr.dll+00222439 mcr::runtime::setInterpreterThreadSingletonToCurrent+00023527
[ 29] 0x0000000015916563                                  bin\win64\mcr.dll+00222563 mcr::runtime::setInterpreterThreadSingletonToCurrent+00023651
[ 30] 0x0000000015916e81                                  bin\win64\mcr.dll+00224897 mcr::runtime::setInterpreterThreadSingletonToCurrent+00025985
[ 31] 0x00000000fd01e647                                  bin\win64\iqm.dll+00583239 iqm::UserEvalPlugin::pre+00030695
[ 32] 0x00000000fd02af8c                                  bin\win64\iqm.dll+00634764 iqm::UserEvalPlugin::pre+00082220
[ 33] 0x00000000fd018770                                  bin\win64\iqm.dll+00558960 iqm::UserEvalPlugin::pre+00006416
[ 34] 0x00000000fd02de9a                                  bin\win64\iqm.dll+00646810 iqm::UserEvalPlugin::pre+00094266
[ 35] 0x00000000fcffad17                                  bin\win64\iqm.dll+00437527 iqm::PackagedTaskPlugin::PackagedTaskPlugin+00000727
[ 36] 0x00000000fcffb36f                                  bin\win64\iqm.dll+00439151 iqm::PackagedTaskPlugin::execute+00000575
[ 37] 0x00000000fcffad89                                  bin\win64\iqm.dll+00437641 iqm::PackagedTaskPlugin::PackagedTaskPlugin+00000841
[ 38] 0x00000000fcffb1e4                                  bin\win64\iqm.dll+00438756 iqm::PackagedTaskPlugin::execute+00000180
[ 39] 0x00000000fcfd111a                                  bin\win64\iqm.dll+00266522 iqm::Iqm::setupIqmFcnPtrs+00072250
[ 40] 0x00000000fcfd0ff3                                  bin\win64\iqm.dll+00266227 iqm::Iqm::setupIqmFcnPtrs+00071955
[ 41] 0x00000000fcfb7b95                                  bin\win64\iqm.dll+00162709 iqm::Iqm::deliver+00003349
[ 42] 0x00000000fcfb8815                                  bin\win64\iqm.dll+00165909 iqm::Iqm::deliver+00006549
[ 43] 0x0000000180106383                        bin\win64\libmwservices.dll+01074051 services::system_events::PpeDispatchHook::dispatchOne+00019811
[ 44] 0x000000018010abe3                        bin\win64\libmwservices.dll+01092579 sysq::addProcessPendingEventsUnitTestHook+00002099
[ 45] 0x000000018010add0                        bin\win64\libmwservices.dll+01093072 sysq::addProcessPendingEventsUnitTestHook+00002592
[ 46] 0x000000018010c095                        bin\win64\libmwservices.dll+01097877 sysq::getCondition+00003269
[ 47] 0x000000018010cf8f                        bin\win64\libmwservices.dll+01101711 svWS_ProcessPendingEvents+00000287
[ 48] 0x000000001591795e                                  bin\win64\mcr.dll+00227678 mcr::runtime::setInterpreterThreadSingletonToCurrent+00028766
[ 49] 0x0000000015918046                                  bin\win64\mcr.dll+00229446 mcr::runtime::setInterpreterThreadSingletonToCurrent+00030534
[ 50] 0x000000001590e832                                  bin\win64\mcr.dll+00190514 mcr_process_events+00010210
[ 51] 0x0000000015910782                                  bin\win64\mcr.dll+00198530 mcr_process_events+00018226
[ 52] 0x000000001581c21e                             bin\win64\MVMLocal.dll+00246302 mvm_server::inproc::LocalFactory::terminate+00073982
[ 53] 0x00000000fa95a3d9                                  bin\win64\mvm.dll+01221593 mvm::detail::initLocalMvmHack+00000521
[ 54] 0x00000000fa95ab25                                  bin\win64\mvm.dll+01223461 mvm::detail::SessionImpl::privateSession+00000533
[ 55] 0x00000000fa95ad31                                  bin\win64\mvm.dll+01223985 mvm::detail::SessionImpl::privateSession+00001057
[ 56] 0x0000000140006fd5                               bin\win64\MATLAB.exe+00028629
[ 57] 0x0000000140007661                               bin\win64\MATLAB.exe+00030305
[ 58] 0x00007ffcd3e97c24                   C:\WINDOWS\System32\KERNEL32.DLL+00097316 BaseThreadInitThunk+00000020
[ 59] 0x00007ffcd540cea1                      C:\WINDOWS\SYSTEM32\ntdll.dll+00446113 RtlUserThreadStart+00000033


This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.

If this problem is reproducible, please submit a Service Request via:
    http://www.mathworks.com/support/contact_us/

A technical support engineer might contact you with further information.

Thank you for your help.

[James Tursa]

We would need to see your mex function source code. It could be that you have some variable type mismatches in the API interfaces.

[Chris Liu]

Hello James,

I put my mex function code below, could you help me see what the problem is ?

#include "fintrf.h"
        subroutine mexFunction(nlhs,plhs,nrhs,prhs)
        implicit none
    
        mwPointer plhs(*),prhs(*)
        integer nlhs,nrhs
        mwPointer mxGetPr
        mwPointer mxCreateDoubleMatrix
        integer mxIsNumeric
        mwPointer mxGetM,mxGetN
        mwPointer Par_ptr,Mat_ptr,sp3max_ptr
        mwPointer mrows1,ncols1,mrows2,ncols2
        mwSize size1,size2
        real*8 Par(18),Mat(2),sp3max
        if(nrhs .ne.2) then
            call mexErrMsgIdAndTxt('Matlab:add:nInput','Two inputs 
     &      required.')
        elseif(nlhs .gt. 1)then
            call mexErrMsgIdAndTxt('Matlab:Add:nOutput','Too many output
     &      arguments.')
        endif
        if(mxIsNumeric(prhs(1)).eq.0)then
            call mexErrMsgIdAndTxt('Matlab:Add:NonNumeric','Input must 
     &      be two numeric arrays.')
        endif
        if(mxIsNumeric(prhs(2)).eq.0)then
            call mexErrMsgIdAndTxt('Matlab:Add:NonNumeric','Input must
     &      be two numeric arrays.')
        endif
        mrows1=mxGetM(prhs(1))
        ncols1=mxGetN(prhs(1))
        if(mrows1.ne.1 .or. ncols1 .ne. 18) then
            call mexErrMsgIdAndTxt('Matlab:sizeArray:IncorrectSize',
     &       'Input #1:''Par'' has incorrect size')
        endif
        mrows2=mxGetM(prhs(2))
        ncols2=mxGetN(prhs(2))
        if(mrows2.ne.1 .or. ncols2 .ne. 2) then
            call mexErrMsgIdAndTxt('Matlab:sizeArray:IncorrectSize',
     &      'Input #2:"Mat" has incorrect size')
        endif
        size1=mrows1*ncols1
        size2=mrows2*ncols2
        Par_ptr=mxGetPr(prhs(1))
        call mxCopyPtrToReal8(Par_ptr,Par,size1)
        Mat_ptr=mxGetPr(prhs(2))
        call mxCopyPtrToReal8(Mat_ptr,Mat,size2)
        plhs(1)=mxCreateDoubleMatrix(1,1,0)
        sp3max_ptr=mxGetPr(plhs(1))
        call les(Mat,Par,sp3max)
        call mxCopyReal8ToPtr(sp3max,sp3max_ptr,1)
    
        return
        end

[James Tursa]

What is the function signature for the les( ) subroutine? (i.e., variable types and sizes of the arguments as specified in the function itself)

[Chris Liu]

James,thanks for you quick reply.

please see this picture

Answer 1

[James Tursa]

In Fortran, NEVER pass literal integers to the API routines because you cannot guarantee the integers will be the correct size needed by the API function. You don't get automatic type promotion in Fortran like you do in C/C++. ALWAYS use explicitly typed variables to pass arguments to API routines in Fortran to ensure that the types match. E.g., this

plhs(1)=mxCreateDoubleMatrix(1,1,0)

should be something like this instead

        mwSize :: ONE = 1
        integer*4 :: ComplexFlag = 0
            :
        plhs(1)=mxCreateDoubleMatrix(ONE,ONE,ComplexFlag)

and this

        call mxCopyReal8ToPtr(sp3max,sp3max_ptr,1)

should be this instead

        call mxCopyReal8ToPtr(sp3max,sp3max_ptr,ONE)

And the doc lists this as the signature for mxIsNumeric

        integer*4 mxIsNumeric

Answer 2

[Chris Liu]

James,thanks for your suggestions.

I updated my code as you recommended, but when I run sp3max.mexw64, it still crashed.

I guess these stack trace may help:

Stack Trace (from fault):
[  0] 0x00007ffc6655ab67 C:\Users\70489\Desktop\Work\columnshell\src\sp3max.mexw64+39955303 MEXFILEREQUIREDAPIVERSION+39950663
[  1] 0x00007ffc63f41246 C:\Users\70489\Desktop\Work\columnshell\src\sp3max.mexw64+00004678 MEXFILEREQUIREDAPIVERSION+00000038
[  2] 0x00007ffc63f41165 C:\Users\70489\Desktop\Work\columnshell\src\sp3max.mexw64+00004453 MEXFUNCTION+00000357

I dont know but does MEXFILEREQUIREDAPIVERSION matters?

I tried using this mexFunction to call another small subrouitne, and compile it into mexw64, then I called it in Matlab successfully. But why does my sp3max.F not work? Since I am able to call it sucessfully in VS.

This problem troubled me for days. Could you give me some other possible analysis? Thank you very much.

[James Tursa]

Pleas post your current mexFunction code

[Chris Liu]

Sorry James, I think I found the root of the problem.

It's because stack overflow as I posted in the first picture.

There're some big arrays in my fortran code, like real*8 na(50000000),

but I am still unable to solve this problem. Do you have any ideas?

[James Tursa]

Variables declared like this get allocated from the stack (a relatively small amount). For large variables, it would be better to allocate them from the heap (basically the entire available computer memory). To do that, make them allocatable and then allocate them inside the function. E.g.,

real*8, allocatable :: x(:), y(:), z(:)
integer status
    :
allocate( x(50000000), stat=status )  ! x will now come from the heap instead of the stack
    :
deallocate(x)

[Chris Liu]

Good news James,I finally solved this problem by allocate those large arrays from the heap.

Although the total stack is still large , it is smaller than 64MB which is the maximal size of stack in Matlab.

Thank you for your patience and help!

[James Tursa]

Glad to hear. Since the stack is used for passing function/subroutine arguments and for allocating local function/subroutine variables, it is best to keep these local variables small in size. If there is any chance they will be large, make them allocatable to come off the heap.

Another gotcha to be aware of is temporary variables. If you do an array operation on large variables in an expression, Fortran may create a temporary variable to hold the results and that may get allocated from the stack (it is up to the compiler where this memory comes from). So even if the large variables came from the heap, an operation on them (e.g., on the rhs of an assignment) might produce a large stack variable and blow up your stack memory. Although it may sound backwards, I actually try to avoid these situations by NOT using array operations on the rhs of an expression when the variables might be large. I will opt to manually write loop(s) for this instead so as to avoid any nasty stack overflows later on if the code gets used with large variables. I might even write it as parallel loops if I think the compiler will not be smart enough to do that on its own in the background. Something to be aware of ...

[Chris Liu]

Great tips! You make me learned a lot again:)