Fortran DLL called from Matlab

TCE Options

TCE Open Date: 

Tuesday, January 14, 2020 - 08:43

Fortran DLL called from Matlab

I created a DLL with Intel Parallel Studio XE 2019 Composer Edition for Fortran Windows.  I'm using it with Visual Studio Community 2015 on Windows 10. I call the DLL from Matlab, and it works great.  But when I want to debug and I "attach to process" Matlab.exe, the debugger works fine with Matlab 2016 and 2017, but not with Matlab 2019a.  Again, when I RUN my Matlab program using 2019a it works fine calling the DLL.  But when I try to debug and "attach to process" the Matlab.exe of 2019a, it won't stop at my breakpoint in the DLL source.  But the other versions of Matlab DO stop at that breakpoint. We're talking about the SAME program source with the same options!  Any ideas would be welcome.

8 posts / 0 new

This is more a MATLAB thing, isn't it? But try this instead of using "attach to process":

In the DLL project, go to the Debugging property page. For Command, put in the full path to your MATLAB executable. Set a breakpoint in your DLL. Now, still in Visual Studio, press F5 to start debugging. MATLAB will start, and when (if) it hits your breakpoint, the debugger will stop.

Do make sure that the DLL you built in VS is the same file being loaded in MATLAB. If it's a different path, the breakpoint won't hit.

Steve (aka "Doctor Fortran") - Retired from Intel

It sounded like a great idea, Steve.  But when I pressed the green arrow, I briefly saw the brown stripe at the bottom as if was in debugging mode, but then that brown stripe disappeared, Matlab loaded, I was able to run the program, but since (for some reason) I was no longer in debug mode, it didn't help.  I guess the question is why didn't it stay in debug mode.  Thanks loads for your help.

It was still in Debug mode, but the debugger would not have become active until the breakpoint was hit. Given what you describe, I'm leaning towards my suggestion that the DLL built in that project isn't the one MATLAB is loading.

Steve (aka "Doctor Fortran") - Retired from Intel

I guess I understand why you would think its not the same DLL.  However, both my Matlab code and my Fortran code are in the same folder.  When I run either version of Matlab, I have to move to that folder to run the Matlab script.  And within the Matlab script, the DLL is specificied as being in the x64/debug/ folder. 

I noticed, Steve, that if I place in the Command space under debug properties the path to the matlab.exe version for which the debugging does work with "attach process", it still won't debug after starting it with F5. Again, the brown debug stripe appears for an instant, but then when I run the matlab script it doesn't stop at the breakpoint in the Fortran code.  I guess I'm doing something wrong.  In any case, I appreciate your suggestions.  Over the years your contributions have solved loads of problems for me.  Thanks!

You could try this..

In the DLL routine, add, after the SUBROUTINE or FUNCTION statement:

use kernel32, only: DebugBreak

Then at the start of the executable code, add:

call DebugBreak

If it executes this call it should stop in the debugger. Make sure you used F5 to start the debug session.

Steve (aka "Doctor Fortran") - Retired from Intel

Thanks again for the suggestion.  But as soon as the routine with the DebugBreak was called, Matlab notified me that an error occurred and it has to close.  In its "closing" report, the end was reached near something dealing with \system32\kernel32.

This suggests to me that MATLAB starts up a separate process to run its user interface. I have no personal experience with that so don't know what to suggest, other than adding code to your DLL that displays or writes to a file intermediate values as it goes along in order to follow the flow.

Steve (aka "Doctor Fortran") - Retired from Intel

Leave a Comment

Please sign in to add a comment. Not a member? Join today