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
Related
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
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)
I have an C++ application, that crashes on a computer of some person on the other end of the world. There's no way for me to simulate it or get the same computer. The person is no developer, so I cannot really ask him to install Visual Studio or something. I have pretty deep debug logs, but they didn't reveal anything usable.
Is there a tool, that could generate the stack trace of the application at the moment of the crash? Such thing is available inside OSX, but seems that Windows doesn't have it.
You can use procdump. It can be setup as a debugger to automatically create dumps for crashing processes.
Procdump is part of Sysinternal tools and can be found at:
http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
Relevant switches:
Create a dump for a hung application:
Write a mini dump for a process named 'hang.exe' when one of it's
Windows is unresponsive for more than 5 seconds:
C:\>procdump -h hang.exe hungwindow.dmp
Automatically create dumps for crashing apps:
Register as the Just-in-Time (AeDebug) debugger. Makes full dumps in
c:\dumps.
C:\>procdump -ma -i c:\dumps
Create a dump for a pid:
C:\>procdump <PID>
You can read the dump files using windbg: Getting started with dump file analysis
Use google's lib that makes minidump for msvc to debug.
CrashRpt
Since google seems to lead here for all "stack traces of windows" you can also get the stack trace of a running process using "sleepy" or "very sleepy" utilities.
another option: run it in gdb.exe, hit ctrl+c
My work platforms are VS2010 and Nsight 3.1.
With Nsight, breakpoints can be set in cuda kernel and the debugger works well. If the breakpoints are set in host code, Nsight just ignores them.
I don't know if it is possible to set breakpoints in host code and use the debugger provided by VS2010. I tried, but the program stops when it meets the first cudaMalloc function. Could someone please tell me how to debug host code in a mixed cuda and c++ program?
Thanks a lot.
I'm afraid you could not debug both CUDA and c++ program in on VS. Here is a workaround. Hope it could help you
Launch a Windows command line. Set NSIGHT_CUDA_DEBUGGER=1
In this command line, execute your CUDA application (Here I suppose it's a long-term execution).
Open a VS. Tools menu ->Attach to Process. Choose transport as Nsight CPU Debugger and attach to your application. Then you could debug CUDA code
Open another VS. Choose transport as Default. Attach to the application then you could debug C++ code
Please pay attention, if the application is suspended by a VS, it could not be debugged by the other VS. You must resume current one and then switch to the other.
I encountered following problem:
I write program in c++ using VS2010. Debug build works properly when run with/without debugging in VS. When I launch built executable directly it also works.
Release build works when run with debugging in VS and alsp when I launch build executable directly.
Unfortunately, program does not work when I run release build in VS -without debugging-. Window is created and then program crashes quickly (without any error message). Since it crashes when run without debugging I don't know how to identify what causes the problem.
Any ideas what might be causing this? Thanks :)
It seems most likely you have some sort of memory error/corruption that just happens to work ok in the debugger.
You can try using couts to isolate how far/where it dies, or try a tool like Purify (or valgrind for free if you can port to Linux).