I've been previously using OpenGL profiler for mac to debug my graphics work and it was working like a charm with xcode 7.2.
I then upgraded xcode to version 8 when it came out, and the profiler was gone. I redownloaded it, but ever since I have not been able to record any trace or stop at any breakpoint, and therefore cannot inspect any resource anymore either.
There is currently no profiler after the one developed for xcode 7.2.
Is there any way to use the last OpenGL profiler with xcode 8.x?
Thanks in advance.
You can find here a similar post on the apple developer forum.
A bug repport is currently under revision.
The only way I found to use OpenGL Profiler on macOS 10.12 is to
enable remote profiling from the preferences. (checkbox is disabled
while you don't set a password) Once enabled, you can connect to it
using another machine (it may be 10.12) and attach profiler to the
running application you want to debug.
Related
I was trying to code with unreal engine 4 (version 4.24.2), but I don't know why, all of a sudden this happen and since then I couldn't do nothing no matter what the version or projects this keeping happening and I don't know what is it or how to fix it
output log error here:
I had the same issue, but it was fixed once I updated to the latest Intel graphics driver.
Check your display driver version.
(In my case, I used gtx1060 and intel graphics630, and only intel driver was not lastet version)
Visit https://downloadcenter.intel.com and update your drivers
I would like to debug some CUDA code in Linux. However, I came across an error that pertains to X11 not being able to share the GPU with the NSight visual debugger using Eclipse Nsight.
However today I came across this.
3.4.2. Single-GPU Debugging with the Desktop Manager Running
CUDA-GDB can be used to debug CUDA applications on the same GPU that
is running the desktop GUI.
Note: This is a BETA feature available on Linux and supports devices
with SM3.5 compute capability. There are two ways to enable this
functionality:
Use the following command: set cuda software_preemption on Export the
following environment variable: CUDA_DEBUGGER_SOFTWARE_PREEMPTION=1
Either of the options above will activate software preemption. These
options must be set prior to running the application. When the GPU
hits a breakpoint or any other event that would normally cause the GPU
to freeze, CUDA-GDB releases the GPU for use by the desktop or other
applications. This enables CUDA-GDB to debug a CUDA application on the
same GPU that is running the desktop GUI, and also enables debugging
of multiple CUDA applications context-switching on the same GPU.
Note: The options listed above are ignored for GPUs with less than
SM3.5 compute capability.
From here: http://docs.nvidia.com/cuda/cuda-gdb/index.html#single-gpu-debugging-with-desktop-manager-running
Question:
So before I ask my project manager for a new compute SM3.5 compute capability graphics card, can anyone verify that this is working?
Does it work well?
My platform is Centos 7.0, Intel 64-bit.
I got the card, anyway in CentOS 7 it works well. There's some slowdown when it goes into the kernel, but it does what I wanted it to. I can see the variable values inside the kernel.
One thing though, as of today 18/2/2016, I cannot press "stop" when debugging kernels. It hangs the whole system. Oh well, it did say it is a beta feature.
I have Kubuntu 14.10 and 15.04 installed on my four computers, all having different hardware (the oldest machine was assembbled in 2007 and the newest just a month ago. I have both 32- and 64-bit OSs installed. The amount of RAM varies from 4 to 32 GB). I have been using Code::Blocks on them for a few months, and I experience the same problem on all 4 machines: integrated debugger is painfully slow when debugging a C++ program.
After the debugger stops at a breakpoint, it takes 10 seconds to 5 minutes to step through a single line of code. And while the debugger is performing a step, one core of my CPU is loaded by GDB by 100%. And often trying to step through a line of code hangs forever. After that I have to kill GDB and the process that has been debugged.
Some time ago I updated GDB to version 7.9 (from 7.8) but this did not fix the problem. And I have no slowdown when debugging with GDB from command line, so I suspect that the problem is in the Code::Blocks debugger plugin.
I saw many complaints regarding similar problems, some of which were allegedly caused by outdated libc6-dbg (more exactly, by the fact that debug symbols were not shipped with Ubuntu and other Debian-based distributions), but reinstalling libc6-dbg did not help either.
I am afraid that after a day or two of trying to fix this problem I will give up and will switch to Eclipse or some other IDE. It looks like Code::Blocks and its debugger plugin have not been updated for a couple of years (at least, their Linux versions). So maybe I should not use Code::Blocks at all because its future is not clear (while Eclipse is likely to be in service for long time).
I wonder if anybody else experiences this problem and whether there are solutions. Overall Code::Blocks IDE looks decent and rather convenient, but this debugger problem prevents from using it for purposes other than writing code and compiling.
An update:
I ended up installing Eclipse for C++ (Luna release). It took some time to learn how to use it. It is slow, buggy, glitchy and uses a lot of RAM, but it at least allows me to debug my applications in IDE. Now I am 100% sure that the problem is in Code::Blocks debugger plugin.
I also tried NetBeans, and seems to work fine, but it is even slower than Eclipse and looks really ugly. So I am going to stick with Eclipse for now because no one seems to be willing to fix the debugger plugin in Code::Blocks.
The problem turned out to be with stepping through lines that declare uninitialized std::string objects. A similar (or the same) problem is described here:
https://sourceware.org/bugzilla/show_bug.cgi?id=12555
The probleb with debugging in Code::Blocks was suddenly fixed when I followed these instructions:
http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_inspect_the_contents_of_STL_containers.3F
on how to enable pretty-printing in Eclipse CDT.
I still need to follow these instructions on my other machines to make sure they fix the problem.
You can try and turn off CodeBlock pretty-printing: Settings->Debugger->Default->Enable Watch Scripts = Unchecked
(Source)
Usually I program on Linux, now I'v setup a Windows environment just to debug with the nsight version of Visual Studio.
But when I try to start the debugger (either Graphics or CUDA Debugging), it doesn't work. The CUDA debugger just disconnects and the Graphics debugger disconnects with
FrameDebugger: Unsupported operation encountered; saving compatibility log to 'C:\Users\##\Documents\NVIDIA Nsight\nvcompatlog.txt'
The file then says
cuGraphicsGLRegisterImage (Registering GL textures for CUDA-Interop is unsupported)
Does it mean there is no way to debug CUDA, when there is interop present? It's hard to believe and so I want to make sure the problem is not on my computer only.
cuGraphicsGLRegisterImage is not supported in Graphics Debugger as the nvcomlog.txt said.
The Cuda Debugger should work. Please contact devtools-support#nvidia.com, you may be asked for the code.
I have downloaded and installed the Qt 5.1.0 for Windows 32-bit (MinGW 4.8) from the qt-project downloads page. I have run the installer, and am able to compile and run applications using these libraries and the minGW 4.8 32-bit toolhchain.
However, I have a large application, and when I try to debug it (using the gdb bundled with the minGW toolchain), it takes an insane amount of time to start running, and any interaction with the application takes a long time to complete. Not an annoying amount of time, but an unusable amount of time. Has anyone else had this problem and are there any solutions?
In case this helps, I get lots of output when debugging like this:
Temporarily disabling breakpoints for unloaded shared library "C:\Qt\Qt5.1.0\5.1.0\mingw48_32\plugins\somefolder\somelib.dll"
There is a gdb bug that was introduced at some point between 7.4 and 7.5, which makes it much slower. When debugging QObject classes, the slower becomes awfully slow.
By disabling debugging helper, you improve it, but then you miss a lot of precious information in the Local Variables and Expressions. For instance, you cannot display nicely the contents of QLists, etc...
It seems that either:
buidling gdb from the CVS or
using an older gdb (7.4.1)
solves the issue.
Qt creator has "attempt quick start" in its gdb options. It helps a LOT.
Or you can switch to using MSVC compiler on Windows. That also switches your debugging to CDB instead of GDB and bypasses the problem entirely. You can just install MSVC compiler and plug it into QtCreator instead of mingw if you don't like MS IDE.
P.S. This also gives you readable core dumps which is a godsend.
See the comments on Zeks' answer. There he explains that switching from the MinGW toolchain to the Microsoft toolchain (compiler, debugger) solves the problem completely. Fortunately, Qt Creator supports the Microsoft toolchain so you don't need to switch IDEs.
After I did that, debugger launch time is now 4sec, and on app crash it there is zero delay. It also sped up builds a lot.
For reference, I've described how I've set up my system here.
I have managed to improve the debugging speed significantly after changing several settings:
Made sure the compiler is gcc.exe and not g++.exe in the Qt5.1.0\Tools\mingw48_32\bin folder
Unchecked Use Debugging Helper in the Tools->Options->Debugger->Locals & Expressions menu
Unchecked Stop when qWarning() is called and Stop when qFatal() is called