Opencv keeps crashing my computer. It seems like it only happens when it is computing very hard. It happens at random times and does not give a blue screen. Just reboots.
Code works completely fine on my i7.
Python 3.9.4
openCV 4.5.3
win 10
AMD Ryzen 9 5900X
Anyone else experienced this or have some insights?
Seems to be some issue with AMD core management. Just running the code on a specific core solved my issue.
On windows, you do that by:
start /affinity X mysript.py
X is the dec of the core combo. 1 will run on core 1, 2 will run on core 2, 3 will run on core 1+2, and so on.
Related
We’ve been trying to get SikuliX 2.0.5 to run on a RHEL 8 system, and not having much luck.
We went through the instructions on this webpage:
https://sikulix-2014.readthedocs.io/en/latest/newslinux.html#newslinux
We started on RHEL 7, but the OpenCV shared library required a newer version of GLIBC than is standard on RHEL 7 (version ‘GLIBC_2.27’ not found (required by ~/.Sikulix/SikuliLibs/libopencv_java430.so)), so we moved up to RHEL 8. We had to build OpenCV (v4.3.0) from source because we could not find a java companion package for RHEL 8, which required quite a few other dependencies, but in the end we got it built with most options enabled, and installed as root on the system. We also got Tesseract installed via a package, as well as xdotool and wmctrl.
We are setting LD_LIBRARY_PATH to ensure that the OpenCV libs are picked up, and when we run with the “-v -c” options to the IDE, there are no obvious problems reported. It seems to believe it is moving the mouse, though we can see that it is not, and when we try to capture a screenshot, the “canvas” from which to capture is either uninitialized/garbage frame buffer memory, or a totally black screen. On rare occasions we have seen the actual desktop, but most times we do not.
Originally the system had 2 monitors, but was subsequently reconfigured to a single display system. We were originally running remotely over NoMachine, but have also tried running locally and observed no difference in behavior.
Any pointers or suggestions would be most welcome. Given that no error messages are being reported, we are out of ideas for how to proceed in debugging the problem. It appears that more native support is provided for Debian-based systems, but we’re attempting to validate a product which only advertises support for RHEL systems, so we’d prefer to get it working in this environment if at all possible.
I've a Acer Aspire 5600U machine, which had windows 10 earlier. I installed Ubuntu 16 on this machine erasing all previous Operating Systems. Now, it says that there is no bootable disk and stuck at the boot screen.
So, i tried to go back to windows 7, and created a bootable Windows 7 x64 USB but the computer does not recognize the bootable USB either, whereas it does recognize bootable Ubutnu 16 OS USB.
I'm pretty sure there must be something i'm missing in the BIOS, but i've no clue what it is. I dont understand the whole concept of UEFI vs BIOS either.
So, if anyone has any ideas to resolve this, would be greatly appreciated.
Thanks
If anyone is struggling with this, here is the problem, how it was got solved.
I had to use Rufus tool to create GBT Partition with FAT32 file system. Looks like the drive i used earlier was in NTFS.
formatting it to FAT32 resolved the issue.
My Bluestacsk2 installation does not pop-up after extracting. Just nothing happens after that window. I tried disabling antivirus programs and running it as administrator. My system fulfils the system requirements:
Windows 10 Pro, 4 GB Ram.
Version: BlueStacks2_native_8e68b6e001e5a05ff01c3f89c5790f9d
I also have the latest version of Directx and .NET framework. My graphic card is up to date and works very well.
This problem occurs only for the Bluestacks 2. I can setup the previous beta version. I tried both win7 and win10 versions for Bluestacks2 but they are not starting to install.
I figured out that I don't have enough space in C drive. But it was really annoying that Bluestacks does not warn me about this. I had several gigabytes in C, but I have been able to install it properly after I removed 10 gb of data from there. (I don't think you need to remove such big data)
I'd like to use SharpDX for the rendering Engine of a WPF project (Windows 7, 64 bit, DirectX10 / 11) but i'm running into problems getting the samples to work. I can use the DirectX 9 samples though. The problem is likely not directly related to SharpDX since i'm also seing similar problems with SlimDX and the other DirectX samples.
The only DirectX driver types that work when using Direct3D 10 / 11 are D3D_DRIVER_TYPE_REFERENCE and D3D_DRIVER_TYPE_WARP. D3D_DRIVER_TYPE_HARDWARE does not seem to be working. This does not only affect SharpDX, C++ samples also let me only choose between RFERENCE and WARP drivers.
My understanding is that those drivertypes are merely software rasterizers. Which implies that my directx installation is not working properly. But i don't see any errors, the latest drivers are installed and the system is reporting the DirectX 11 drivers and the Graphics adapter supports DirectX 11.
dxdiag is not reporting any errors
dxdiag confirms that DirectX 11 drivers are installed
I'm using a GT 460, which should support DirectX 11
System is Windows 7 (64bit) / VS2013
SharpDX is able to create the devices but as soon as a VertexShader is created or a SwapChain is set up i get DXGI_NOT_SUPPORTED or E_NOINTERFACE errors.
I already swapped Graphics cards from a Radeon HD 5450 to a Nvidia Geforce GT 460 to no avail. The sharpdx samples run fine on another computer with Windows 7 and Intel on board graphics. Can anyone give my an idea what is going on here? Why can i only use Warp and Reference drivers despite having a DirectX11 capable Graphics adapter?
Any help is greatly appreciated. The only references i found online to such an issue was someone running the IDE inside a VM that did not have proper 3d drivers.
We recently moved from Windows XP to Windows 7 and ever since the move I've found that I can't run the !dlk command from Sosex in WinDbg anymore, it simply runs forever. It used to be a handy way to catch deadlocks in our code.
Did something change in Sosex that I should know about?
We're on Windows 7 64 bit debugging a crash dump from a x86 process that ran on a Windows 7 64 bit machine.
In the meantime I can try and work through !syncblk, but !dlk was sooooo nice.
As Rockstart said in a comment, major performance improvements have been made to SOSEX in recent weeks. Please let us know if you continue to have difficulty with the latest version of SOSEX. You can also email the address listed in !sosex.help for support.