I'm currently developing a mex-file with CUDA functionality to be used in MATLAB. When I'm doing something wrong (e.g. wrong pointers or something like that), MATLAB always crashes (windows prompts me to end, send the report for mathworks or attempt to continue). Is there a way to prevent this from happening? It's really annoying to develop like that but as you probably know yourself: Hardly anybody can write perfect code without 'trial and error'...
Thanks so far!
As far as I know, there is no way to prevent Matlab from crashing on a mex bug. But you may be able to attach a debugger to the Matlab process and step through the code.
I know for a fact that this works if your code is in an external dll that you load into Matlab. I am not sure if this works with mex files.
From the Matlab MEX file page,
mex -g yourmexfile.c
if you're not doing this already.
You can debug Matlab mexfiles including CUDA codes using Visual Studio and NVIDIA Nsight for Visual Studio by the following procedure.
Define the system environmental variable NSIGHT_CUDA_DEBUGGER and set it to 1.
Launch Matlab.
Launch NVIDIA Nsight. Right click on the Nsight Monitor icon on the taskbar and select Options. Select the CUDA tab. For the option Use this Monitor for CUDA attach, click the drop-down menu and select True.
Open your project in Visual Studio, set the breakpoints and compile it.
Go to Tools -> Attach to Process.
Click the drop-down menu next to the Transport field, and choose Nsight GPU Debugger.
Ensure that your host machine name is listed in the Qualifier field.
Note that this field is blank by default; you will have to manually select your machine name the first time this dialog is opened.
When you enter your computer's hostname in the Qualifier field, a list of available processes will appear in the dialog box. Processes that may be attached with CUDA usage will appear with CUDA listed in the Type column. If a process is grayed out and CUDA is listed in the Type column, it is already being debugged, so it is not attachable. Processes that are grayed out without CUDA in the Type column indicates that it has no CUDA usage in the process to be debugged. Processes that may be attached will appear normally, and the Attach button will be enabled.
Ensure that Matlab has CUDA in the Type column and select it.
From the Matlab command line, invoke the function defined in the CUDA mexfile. The execution will then stop at the first breakpoint and debugging could start.
Related
I'm tasked with upgrading a lot of legacy models and scripts made in an older version of Matlab/Simulink and have it running smoothly in R2018b. Among other requirements I'm not allowed to have any warnings issued upon execution of .m scripts or Simulink models. This is generally tedious but straightforward to comply.
However, there is a specific warning that Matlab does not give me hints on possible sources:
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more information click here.
The link opens the Matlab Help page titled Resolving Low-Level Graphics Issues, which describes issues I'm not finding (or at least not noticing)
I do note that many scripts I run create and close figures, but this is done procedurally. I haven't been able to associate this warning with some specific function or feature. I'm working on a Windows Server machine.
Does anyone have an idea of how to narrow down which kind of function os Simulink block could cause this warning?
As datenwolf and Ander point out, the first thing to try is to update your drivers. If this doesn't work, and your only problem is that you're getting the warning but your graphics still render fine, then you have two other options to try.
First, you can simply modify your OpenGL rendering preferences using opengl. The following will set your preference to 'software' and save that setting for future sessions:
opengl('save', 'software');
Alternatively, you can just try to suppress that particular warning message. After you get the warning, issue this call to the warning function:
w = warning('query', 'last');
The w.identifier field will give you the ID for the warning message, which I believe will be 'MATLAB:hg:AutoSoftwareOpenGL' in this case. You can then add the following line to your startup.m file so that this warning is suppressed every time MATLAB is opened:
warning('off', 'MATLAB:hg:AutoSoftwareOpenGL');
Install the original vendor drivers for your GPU. The drivers that are installed by Windows by default lack full OpenGL support. Download the driver package directly from the website of Intel, AMD or NVidia, depending on what GPU you have.
If you don't have GPU, for example when running in a Virtual Machine, then you can not avoid that warning, because then Matlab has no other choice than falling back on the software OpenGL implementation that it ships with.
There's nothing you can do about that, other than making sure, that the system you're running Matlab on, does have proper OpenGL support!
It took me a long time to get it, so I'll put you here in case it helps how I managed to activate openGL in Linux:
If you haven't already (it's common for other problems), rename libstdc++ library from MATLAB:
mv _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6 _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6.bak
Create this link: sudo ln -s /usr/lib/x86_64-linux-gnu/dri/ /usr/lib/
Run export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER;matlab -desktop -nosoftwareopeng
Your DRI Driver will be a file from /usr/lib/dri, removing "_dri" (in my case was the "radeons" driver for an AMD Vega graphic card.
Run MATLAB from a terminal using: export MESA_LOADER_DRIVER_OVERRIDE=_YOUR_DRIVER_HERE_;matlab -desktop -nosoftwareopengl. YOUR_DRIVER_HERE should be your driver, radeonsi in my case.
Check openGL with info = rendererinfo
If something went wrong, you will be able to see in the terminal which library was responsible. Executing 4) and 5) I was discovering what I had to correct, you can do the same if you have another problem that has not appeared to me.
So that it always runs correctly I put export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER at the beginning of the script that runs matlab (_YOUR_MATLAB_FOLDER/bin/matlab), although I suppose it can also be set as an environment variable.
I hope this has been useful to you.
I'm attempting to program very basic VHDL on eclipse using the Sigasi plugin with an educational license - with the aim to be, I can program a simple entity and a test bench for it, then compile and simulate it in Xilinx's ISim.
I have installed Eclipse, Sigasi & Xilinx ISE Webpack, and have attempted to add the ISim toolchain to Eclipse as shown in the Sigasi website here
It appears okay but it says I need to "activate" the toolchain (as shown below)
However, when I follow the "click here to activate now", I get taken to the scree below - from which nothing happens. If I click Apply, nothing happens, there's no further options!
My question - how do I actually configure ISim to launch from Eclipse, is what I want to do actually possible or have I misunderstood and if so, how do I do it.
Thanks very much for your help!
David
When you enable the ISim toolchain, Sigasi will automatically compile your files with ISim when you save your files. You can check the output in the Console View
To start a simulation, you need to set a top-level first. You can do this in the Hierarchy View. Next, click on the Simulate button.
You can find more details in the Sigasi Studio manual
I have a Simulink model that uses an s_function, which is a mexw32 file. The s_function block uses a .lib module as well. Now, when I'm trying to run the model Matlab crash before the simulation end and without any errors in the command window. What are my options for debugging if Matlab crash?
This is typical behaviour of a badly written S-function that is causing a seg-fault. Debug it using the steps outlined at: http://www.mathworks.com/support/solutions/en/data/1-3KK6RK/
I dont know about Simulink or S-functions (never used them), but usually when a MEX-file segfaults, MATLAB will recover from it most of the times, showing a stack trace and placing you in the "you need to restart MATLAB" command prompt mode. You'll find a crash dump and error log files in the system %TMP% folder.
As other have said, if you have access to the source code of the MEX-function, recompile it with debugging symbols, attach a debugger to MATLAB, place breakpoints in the debugger, and initiate the MEX-function by calling it from MATLAB. Once inside the C code, debug it code step by step until you find the problem.
Here is the relevant doc page describing this process in more details.
You mentioned that your MEX-executable is linked against an external library. So you might also want to check that for the source of the problem.
I am trying to run a model in Simulink, available for download here (direct).
I have been able to run it on a Linux machine, but on Windows it seems to get stuck at the compiling step. At the bottom of the screen I see two green bars, and the message "compiling: evaluating block parameters." It never goes beyond this.
I have tried choosing a compiler using the mex -setup process, but to be honest, I suspect this is not even close to what I need to do.
Any advice would be appreciated.
My program works great with windows xp. I am trying to add some more functionality and using OutputDebugString() to show some debug information. works flawlessly on XP. Now when i want to use the same program on windows 7x64. I dont see any output in DebugView.
F1! F1! F1!
Sorry for reviving an old question, but we spent a good couple of days searching the internet to answer this one and eventually ended up logging a connect call. I am posting here to help anyone else in the same situation. Our specific problem was getting the output from OutputDebugString, MFC TRACE etc in the debug output window when debugging an x64, mixed mode application.
According to Microsoft, apparently for debugging x64 mixed mode applications the debugger type of 'auto' (set in the Debugging->Debugger Type property page) defaults to managed rather than mixed. This will need to be explicitly set to 'Mixed' for both managed and native debug output to be seen when debugging a 64 bit build.
There are a number of reasons why this may or may not work. I accidentally disabled this -- here are all the things you need to check to get this working:
Is the debug output text getting redirected from the Output pane to the Immediate pane, thus you are not seeing it? To turn this off:
Debug
Options and Settings
[ ] Redirect all Output Windows text to the Immediate Window
Is the Output pane visible?
Debug
Windows
Output
In the Output pane do you have Program Output enabled?
Debug
Windows
Output
Right-Click anywhere inside the pane
[x] Program Output
Do you have the right Debugging Type selected?
In the Solution Explorer (View > Solution Explorer) pane
Right-click on your project
Properties
Debugging
Debugging Type: change from Auto to either Native or Mixed
Is the debugger tried to get attached before the program has started? To turn Attach off:
In the Solution Explorer (View > Solution Explorer) pane
Right-click on your project,
Properties
Debugging
Attach: change to No
Are you using OutputDebugStringW()? Try using OutputDebugStringA() instead.
Lastly, did you start the program in debugging mode? :-) Hey, you never know!
Debug
Start Debugging (F5)
I hadn't seen a comprehensive list before so the above are all the things I had to verify were set correctly.
3 small suggestions:
make sure you are actually capturing events (top menu -> capture -> capture win32 is marked)
if you program is running in low integrity (does it give a security warning when you are running it) you need to run debug view in low integrity as well. to do that you need to change the integrity level of dbgview.exe before running it.
if you are using visual studio and running with debugger (pressed F5) then the debug output is actually captured by visual studio (in the output window). try running your program with ctrl f5.