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.
Related
I created a MATLAB script for controller through wizards and uncommented
desktop; keyboard;
to interact with the MATLAB interface. Works are done on Win10.
My code works, but I have to start the MATLAB program from Webots to grant MATLAB access to Webots library. I tried opening MATLAB alone and had no clue about linking the program to Webots lib and project.
Another drawback is that every time I modify the codes and reset the simulation in Webots, MATLAB is restarted, which is annoying since it takes quite a time.
Q: Is there any way to link MATLAB to Webots lib so that I can develop the controller in MATLAB alone without starting Webots?
Maybe below solve your problem.
Solution
In the launcher.m file (..\Webots\lib\controller\matlab):
Change each line containing 'lib/matlab' to 'lib/controller/matlab'
Lines are 15, 23, 132
and
In allincludes.h (..\Webots\lib\controller\matlab):
Change each include path so that it goes back a further directory
eg: #include "../../../include/controller/c/webots/accelerometer.h"
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 am new to matlab and I've installed it successfully. Everything works fine. But when ever I try to open .m files, I always get following error popping out of dialog box:
Error using open(line 162)
Failed to open matlab editor.
And in command window it throws a lot of Java exceptions.
First of all please forgive my poor English.
I've been searching for this problem all over the internet but couldn't find any useful solution.
I'm using windows 8.1 pro 64-bit os.
Your error message indicates that there is an error in a line that justs consists of
<br>
This is not valid matlab code (looks more like html). As such it seems like you have either messed up the open function, or overloaded it somehow.
I think the first thing to do is check which open and see where this points you.
If this does not help, try to look at the matlab path carefully and see whether you accidentally added a (html?) file on it called open.m.
Lastly, you could try to use the built in open function directly, check doc builtin for this. If you succeed at least you are sure it is not a matter of corrupting the standard file.
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.
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.