- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page