I'm using xming 6.9.0.31 on Windows XP computer to connect to Linux server and run Matlab scripts there. I have 2 configurations of xming and both have problems related to matlab output figures.
In one configuration everything works on the first script run, all figures come fine. But on the second run (of the same script) xming crashes when it outputs some figures. It might work longer if i create figures in command line, but eventually it will crash anyway, on the process of outputting new figure.
In another configuration (borrowed from andLinux installation) xming doesn't crash and is able to output figures, but only simple plots, if there is something more complicated, with a lot of data, just figure frame appears with whatever was under the figure window. The same thing happens if i actually run andLinux and connect to Matlab from there.
Seems that this is somehow related to memory. Are there any options for xming which are related to used memory? As far as i understand it'a only showing the image which was created on the server side?
If the issue is related to OpenGl setting another renderer might help.
set(gcf,'Renderer','Zbuffer')
Related
I am working on a non-linear network-optimization problem. When I run a large problem instance on the lab high-performance computers (imposing the time limit of 1 or 2 hours), those computers give me the output when the time is exhausted.
I wanted to use Google Collab to run the same code and to share it with my supervisors (they don't have Pyscipopt installed on their computers). However, when the problem size is small – all is good, but when the problem size is large, it says that the execution is completed (on the bottom of the screen) along with the time it took and a small red exclamation mark BUT it does not show any output for the large-size network optimization problems (neither it prints the solution nor it explains what is the reason/error of this behaviour).
Again, the same code works perfectly fine on high-performance computers, so I do not think there are any problems with syntax.
Please let me know if there are any solutions to the problem described.
Kind regards,
Lidiia
I tried to change "None" in the hardware accelerator to GPU and CPU. I tried to proofread the code in order to find any mistakes. I tried to not leave the Google Collab to run the code at night (I read somewhere that kernel stops working if there is inactivity) so I tried to click on something there to prevent the execution from stopping. Nothing worked.
I've written a shared library in C/C++ for MATLAB to create an API for a Monochrome camera.
The code works, but I have some odd issues with memory management (basically the MATLAB functions for freeing/dynamically allocating aren't too reliable). Additionally I have some other really low level things I'd like to debug like looking at values of register holding raw camera buffer.
I can write standalone C Code and launch it with GDB, however a child process will crash the software as only 1 thread is allowed to open a connection to camera at a time. If I don't set break points within the code interacting with device all is fine. But I want to stop the program say after acquiring image buffer, but before copying the data into MATLAB output, the child process spawned by the debugger causes everything to lock up.
Anyone know how I might address this?
Edit: "Unreliable" is not a good wording. Basically, I retrieve an image buffer from camera (which is dynamically allocated because image bitdepth is variable). This array is created/destroyed with mxMalloc and mxDestroyArray which works okay if I have MATLAB_MEM_MGR enabled. This is part of what I would like to debug inside MEX. The other is comparing the raw byte values of the image buffer before coming back to matlab.
Additional Clarification:
The error I get in GDB is actually a GenICam error for RESOURCE_IN_USE. My intuition is because the parent process hasn't released the camera resources, the child thread started actually causes issues if that makes sense.
On Windows, it seems somewhat dangerous to switch from VC++ to MinGW-w64 for a MEX, as you can easily wind up with the classic Windows bug of having multiple copies of libc. See the warning here, "Do not link to library files compiled with non-MinGW compilers". A MEX built with 'gcc' will pull in malloc() and free() from msvcrt.dll, whereas any DLLs you link against that were built with 'cl' will pull in ucrtbase.dll instead. That could easily lead to crashes, if for instance gcc-compiled code calls free() on a block allocated using malloc() in cl-compiled code.
The gdb.exe installed by MATLAB does seem to behave somewhat strangely, especially when I press Control-C. It doesn't like Cygwin terminals either. It does spawn a weird 'gdborig' helper process. Finally, I kept seeing a Microsoft A/V tool, mpcmdrun, firing off as I was playing with it. You might try the newer gdb installed by MSYS2 (although I may have seen A/V there as well).
Indeed, some random child process probably inherited the device connection handle, causing the lock-up. But that child process might be something else... not be the extra one created by that silly old version of gdb (7.11.1).
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 have a script that generates a slew of figures for a manuscript. It crawls through a directory, loads in some data files, performs some calculations, formats the results into some figures and then outputs the figures to png and/or pdf files for inclusion into my manuscript using export_fig.
My problem is that the "performs some calculations" part is slow, and my directory to crawl through is reasonably sized. I would like to run the script on another machine so I can be getting other work done on my regular desktop machine. However, when I remote desktop into the other machine (between two Windows 7 Enterprise machines), as soon as I set things to run and minimize the RDP window, MATLAB throws the following error:
Error using drawnow
UIJ_AreThereWindowShowsPending - timeout waiting for window to show up
Clearly, the fact that there is no window for MATLAB to draw to is causing it problems. However, I have run this script overnight before, where the lock screen takes over, and not had a problem.
My question is, is there a way to tell MATLAB to draw the figure even if the display is a minimized RDP window, or do I have to physically log onto the computer to generate the figures?
I am using Matlab on a remote server from my MacBook. Partly because I find the Matlab GUI clunky under X11, I use it in the terminal window (by running matlab -nodesktop). This has been working fine, until I now needed to copy some stuff from the command history.
It seems like history.m is only being saved on exit, even though when I check the settings in the GUI, it says that it is being saved for each command. It also seems like exit statements are included in history.m when Matlab is run from terminal, but not in the GUI, so it seems like the settings in the GUI don't apply there. I cannot find anything in the Matlab help pages on how to change the settings for the terminal window.
I need to access the command history for my session while it is still open. Does anybody have an idea about how I can do this -- short of starting to use the GUI?
You might try the diary function. It logs both commands and their (text based) results to a file. On my system (Mac OSX with MATLAB R2011b), the output does not show up in the diary file immediately, but it does update when you turn off the diary. Which you can do repeatedly if you need without exiting matlab.