Why do profilers fail to get information from my program? - c++

I am trying to profile a C++ program but whenever I run a profiler I get no information even though the debug information works as I can run a debugger on it.
I tried using AMD uProf, Very Sleepy and Visual Studio but all of them give me no information. No functions get detected.
The program is compiled using clang-cl and runs for only a few milliseconds.

It seems like Windows Defender was messing with somethings, it has caused me some trouble in the past as well. Disabling it and rebooting seems to have fixed the problem. Also due to the program having such a short execution time most profilers aren't able to get enough samples

Related

Headless debugging on Windows

There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)

Console Window does not appear using Dev C++

When I compile and run my code, the console window no longer shows up.
(I have "system("pause");" included, this is not the issue).
I was trying to debug a program in Dev C++ and must have changed some settings. Any advice?
Dev-C++ is really old and the debugger is full of bugs. If you're sure the problem isn't with your code, then I'm assuming you've tried the basics, like restarting Dev-C++ and restarting the computer?
If that doesn't work, try reinstalling Dev-C++... It only takes a couple seconds to install it.
You can also try stepping the code.

gdb is very slow when running with netbeans and c++

I am trying to debug a c++ linux program using netbeans and its very slow.
when looking at the netbeans debugger console, I see that it's using gdb and making it printout a lot of information about call stack and variables. I don't need all the information, how do i make netbeans stop asking for it?
More specifically. Netbeans keep calling stack-list-arguments. my stack is very verbose, so is causes about 10 seconds delay for each single step

C++ 64bit, variable not found

I have a problem with my C++ application. It was developed on a 32bit pc, on Microsoft Visual Studio 2008, and now I am trying to run it on a 64bit pc.
On my 32bit pc it works fine; on the 64bit pc, Visual Studio does not give any compilation problem, but then on execution gives wrong results.
And I have undestood why.
In the code, I define a variable, of tipe "dag", that is a structure for a direct acyclic graph. By debugging the software, I noticed that, although I declared it, later the software is not able to insert data in it, and the debugger says:
CXX0017: Error: symbol "dags" not found
Here's my code:
Dag<int64_t>* dags = new Dag<int64_t>();
dags = getDagsFromRequest2(request, dags);
The very strange thing is that, if I follow the flow inside getDagsFromRequest2() function, I can clearly see that dags variable is full of data: on "quickwatch", it shows 2342 nodes inside it. But when I come back from getDagsFromRequest2() function to this part of the code, debugger says "CXX0017: Error: symbol "dags" not found". How is it possible?
You can also see this screenshot from my Visual Studio debug set.
What could be the problem?
Thanks a lot
There are a few possibilities to consider:
Running in Release builds. Switch to a Debug build.
Using a Debug build that has optimizations enabled and/or debug information disabled. Disable the optimizations and enable the debug information (look in another project for the relevant settings).
A corrupt build of some sort. Clean and rebuild the entire solution.
Memory corruption which is preventing the debugger from displaying the variable. Ensure that no memory issues exist with a tool like Valgrind.
A VS bug. This report for VS2010 seems to suggest a known bug with similar characteristics for example. Ensure all patches and hotfixes for VS2008 are installed.
The variable dags is defined as your code compiles. The error you see is simply related to the debugger. I am guessing it is caused by running the application in Release mode which sometimes causes confusing and wrong watches values. Try changing the mode to debug(there is a drop down from which you can choose the build mode).
EDIT: as you say you are running in Debug mode, my next guess is that this behavior could be caused by stack corruption. Try using valgrind to detect if that is the case. It may take a while to start with it,but it is worth it and will detect if you have some memory corruption.

My C++ executable runs way faster outside the Visual Studio 2008 IDE than inside, even in release

I build a C++ application that does some number crunching.
I'm running in Visual Studio 2008 PRO SP1, in release mode, Windows 7 64 bit.
If I run it inside the IDE, the application takes 4 minutes, if I run the same executable from windows explorer it takes 6 seconds!
I have no clue. I have checked that this does not depend on the processor and operating system. I don't think I have strange VS plugins that are doing something in the background.
Any hints?
Thank you in advance!
Marco
Presumably, the slow down is caused by the debugger being attached when you are starting the application in Visual Studio. This is the case even when you've built the program in "Release" mode.
To confirm that this is indeed the source of your problem, try running your application without the debugger, using the "Start Without Debugging" command or Ctrl+F5.
It's worth nothing that in C++ specifically, when you start without debugging, your program won't use the Windows debug heap. With the debugger attached, it will.
As Cody mentioned, one option is to simply not debug. But if you want to speed up your debugging sessions, here are a few things I've found can make a huge difference:
Remove debugging print statements that are no longer necessary. If you see your log filling up with text, that is likely slowing you down significantly.
Remove breakpoints (Ctrl+Shift+F5). A couple times I've noticed a huge drop in performance, and it turned out to be due to a breakpoint with a condition that was never met.