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).
Related
I'm trying to debug a relatively simple OS using QEMU and GDB.
The problem is that the bootloader loads the OS executable and then randomly relocates the OS code and data pages to different parts of memory. This is to implement the Address Space Layout Randomisation (ASLR) security feature.
The OS executable has been built with debug symbols, so in theory, I just need to tell the GDB debugger where these symbols are in memory. However, because they have been randomly relocated, I have no idea where they are.
Are there any GDB commands or scripts I can use to find the different parts of the executable in memory? Maybe based on code fingerprinting?
However, because they have been randomly relocated, I have no idea where they are.
There are two usual approaches to this:
disable ASLR to ease debugging
have the loader print the relocated address (which you can then use to tell GDB where the relocated object resides).
Are there any GDB commands or scripts I can use to find the different parts of the executable in memory?
Yes, you can use the GDB find command if you there is a known byte sequence you are looking for.
I have encountered a critical issue that Unity Editor freezes. I've spent many hours debugging step by step of my codes but still can't find where the problem is. So I think maybe I should try thinking from another angle, generally speaking what reasons would cause Unity Editor freezes and not responding?
I can't find a general case discussion about this topic.
From my experience, infinite loop is one reason for sure. Deadlock is critical issue, but not sure if it causes Unity Editor freezes. Unity Editor bug that I encountered only makes the whole editor crashes, instead of freezing. Any other experiences are welcomed. Thank you!
In such case, what kind of tools or methods could I use to debug it? Right now since the editor freezes I can't use "print" to find out what happens after it freezes. So I use Visual studio to debug the Editor thread, in this way I can see all the prints that I wrote. It appears the game is still running, only the editor not responding. And I can use VS click "attach to Unity and play" and put some debugging points, then debug step by step.
The first thing that I would check out is for an infinite loop. At the hang/freeze moment, you can attatch the debugger of your choice and pause the execution. In the case that it is an infinite loop that it is executing, at the exec time pause you might find the execution in a forever running while (true) {...}
Other thing that I would check is the plugins in use. Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang. Source
To check that you can check the active threads in the visual studio command window af the freeze is reproduced:
View->OtherWindows->CommandWindow and type in this command:
Debug.ListCallStack /AllThreads /ShowExternalCode
In the stack you can check if some thread is there with no need, or if its related with the plugins mentioned above.
Also an interesting point is to check in the windows task manager (in the case that you are using windows) if the CPU usage is to 0%. It can lead you to the type of hang that is taking place.
Good luck.
Edit: I forgot to mention, you need to check also the unity logfiles
I notice this all the time, and its super frustrating.
Unfortunately, this could be any number of issues. I notice this issue most often when working in projects that are made for the Universal Windows Platform.
Try using the Task manager to monitor specific processes / threads running.
Some follow up questions:
What platform is your project currently targeting?
What version of Unity are you running? Have you tried other versions?
What are your computers specs? Is the OS up to date? Graphics Drivers?
Does it happen (or happen more often) when an external code editor is open? Perhaps try going to Preferences>External Editor > Regenerate Project files.
Are you using Unity Collab by chance? I've had issues where collab is stuck trying to communicate with Unity Servers / looking for changes. Try logging out of your Unity account through the editor, and log back in.
Have you tried looking for a Unity editor crash dump, or error log files? I think they can be found here C:\Users\username\AppData\LocalLow\Unity by default. Those files may give you more specific data concerning your problem.
Unity's new versions are getting more slower and slower. From my experience 2019 versions are the best and more stable.
I solved my issue. It's fundamentally an infinite loop.
It's not a simple case such as "while(true)". I'll try to explain.
My game was a PvP game, and I'm making a local AI. Usually my design pattern works fine, however I just turned off the simulation of "AI thinking time", and since the AI codes and server codes all run in local mode, the transmitting of data between server and client are replaced by local method call(meaning instantly executed before everything else).
There is a loophole in my server code. I use "Update" and a flag on server to change a specific game state, however in this particular case, it got into an infinite loop because the local method call is executed before the "Update". And because my AI now doesn't need real time to "think", it "acts" and transmits the event data to server right away. And since the transmitting doesn't need time any more, it calls the server method instantly, hence forming the infinite loop.
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.
Setup: Matlab Student 2014, Psychtoolbox 3.0.12, GStreamer 1.4.3, ATI Radeon 69xx, all on Windows 7, all 64bit.
Screen works with different arguments, only at Screen('OpenMovie' the whole Program (Matlab) crashes - sometimes with Error (unable to synchronize framerate), sometimes no error at all.
I know it is quite specific and I think it is somehow in my configuration (the code will work on a different system (lab)).
What I've tried so far:
Psychtoolbox 3.0.11, GStreamer SDK, GStreamer 1.4.1
renewed ATI drivers (complete catalyst control center,..)
removed multi-monitor setting (makes it harder to debug then..)
Matlab itself works, GStreamer too (tried playing movie with playbin)
anything SyncTrouble states: wait for vertical synch, triple buffering off
overriding sync-tests or skipping at all (also crash)
looking for missing dlls (for Screen.mexw64)
VBLSyncTest and PerceptualVBLSyncTest look fine and have results (for me)
It has to be either something very simple, or very specific - I'm somehow out of ideas. My guess would be that the Radeon vertical sync on setting does not work - for what reason ever.
ANY guesses, tips are apreciated. (even other ways to test Screen or vertical sync in Matlab/Psychtoolbox)
after hours of search, I think I've found a solution - oh Windows! (and oh, one simple line of code)
Screen('Preference', 'ConserveVRAM', 4096);
4096 == kPsychUseBeampositionQueryWorkaround
Tell PTB to always use the workaround for broken beamposition queries in
VBL on MS-Windows, even if the automatic startup test does not detect any
problems. This for rare cases where the test fails to detect broken
setups. [Psychtoolbox Docs]
I will do a recheck after some Videocache action and restarts.
edit:
well, that did only work once, and randomly a second time - it seems like the ATI Radeon driver behave not quite deterministically - I also checked on a Linux (Ubuntu 14.04.1). Specifically, the VSync rate seems to behave somehow strangely.
It generally works on that specified Linux with the open source radeon drivers (instead of the fglrx ones) though. -> The Problem on that Linux system: it can only be configured as one Screen (two monitor setup would be nice for debug on one Screen). (Yes, I've tried: Unity, Gnome, Xmonad, Gnome+Xmonad - but I guess that is another story)
Alright, I've written enough, my solution: use a Linux distro (quite unsatisfying though, as I could not accomplish for everything to work).
My client has an old version of uClinux, kernel 2.6.22, running on a Blackfin STAMP board. The main application is divided into 14 processes, plus there's a webserver running on the board.
The bug we're seeing, the webserver keeps running happily along while the VOIP application seems to run out of file handles and can't create new sockets. I've tried every debugging technique I know of. I have a JTAG debugger but the memory is too small for debug symbols. I can't compile with Valgrind or anything like that. Any guesses?
Thanks,
Mike
It's likely you've got a file descriptor leak. Valgrind isn't the best tool for tracking that down anyway.
Start by doing 'ls -lah /proc/pid/fd'. That'll show you a list of file descriptors opened (and not yet closed) by the process.
If you've really got a file descriptor leak you should see a lot of entries there. It should also be immediately obvious which type of file descriptor you're leaking (file, socket, ...).
Once you know that you'll have a better idea of where in the code to look for the leak.
The fact that your file system is full may be another hint. If your application is creating a file and removing it, but not closing the file descriptor, you might have a bunch of files which you won't find in the tree but which still eat up space hanging around. In that case you'll see the file names in (the target of the symlinks in) /proc/pid/fd.