What are some advantages to a GUI debugger like in Eclipse and what are some advantages to using a command line debugger such as gdb? Does industry use command line debuggers? and if so, what situations do people use command line debuggers?
I usually use gdb, but some advantages I can think of off the top of my head:
Being command line, debugging binaries on remote systems is as easy as opening an ssh connection.
Great scripting support, and the ability to run many commands per breakpoint (See the continue keyword)
Much shorter start-up time and a faster development cycle.
Copy&pastable commands and definable functions that let you repeat common commands easier
gdb also speaks a well-defined protocol, so you can debug code running on lots of obscure hardware and kernels.
Typing short commands is shorter and more efficient in the long run than working around a GUI (in my opinion).
However, if you're next to a system or runtime you've never used before, using a visual debugger can be easier to get started from the get-go. Also, having your debugger be tightly integrated with your IDE (if you use one) can be a big boost in productivity.
Visual debugger and command line ones don't have to be completely separate, there are visual front ends for gdb, such as DDD. (I don't use DDD however since it feels ultra kludgy and outdated. It does exist though. XCode also wraps gdb for debugging support)
Command line debugger is good for debugging a remote system (especially when the connection is slow), it is also useful for low performance systems or systems without Xserver/graphic card. CLI debuggers are also used for quick analysis or core dump and SIGSEGVs (they are faster to start). Command-line debuggers are more portable, they are installed almost on every system (or them can be easily installed, or even started from network/flash drive)
I think that command-line can be used for programs without source, and the graphical debuggers are better for projects with complex data structures/classes.
Another situation is that command-line debuggers easier to automatize, e.g. I have a shell script, which do a full call graph logging of program using gdb. It will be very hard to automate a graphic debugger.
It's essentially impossible to compare meaningfully based on the debugger's display. People who like command lines are likely to use text mode, command-driven debuggers. People who like GUIs are likely to use graphical, menu-driven debuggers.
Nearly the only time there's a really strong technical motivation toward one or the other is if you're debugging a windowing system. For example, using a debugger that depends on a having a functional X Server doesn't work very well if what you're trying to debug is the X Server itself.
Related
I am developing multithread application with c++ using eclipse cdt. I need to debug my code, i have tried to write to console by using printf but it is not very useful. How do i debug my multithread code?
It depends on what you're looking for, but debugging multithreaded applications can be very similar or extremely dissimilar to debugging single threaded apps.
First, some example methods you can still use:
Use breakpoints with an IDE
Use various solid relevant debugging tools such as Valgrind. Here's a link to a good article full of tools: C++ TUTORIAL MULTI-THREADED PROGRAMMING DEBUGGING - 2020
Output to separate files OR use locks if outputting to the same file/stream (not recommended but will touch on this)
I assume the issue you're running into here with printf is that it's like multiple threads writing to the same file- it's a race condition for what output you'll see on the screen. I'd personally still recommend using a tool like valgrind if you're running into a multithreaded error, but if you'd like to continue using simple console output, try...
Write to different files instead of to standard output/the console
Use a lock/mutex to assure only 1 thread is writing to standard output at the same time (which could mask race condition or such issues due to adding in blocking for that lock before printing)
A more so wild idea: Share state (via a lock to avoid multiple threads reading or writing to the data at the same time) or otherwise return output to a single thread that's dedicated to writing out your debug info. Similar to the above but slightly different in implementation and useful if you'd like to design in a dedicated multithreaded log system for future improvements
All in all, the exact tool you should be using here depends on the exact issue you're facing and thus no strong recommendations just yet. Please apply the tools above (including breakpoints in Eclipse) to suit your situation.
I have a situation where I am working with a multithreaded C++ program in CentOS (Linux) and am trying to figure out which portion of the program is the "CPU resource hog". I have already identified the offending thread using the "top" command from the console. Now my question is, how can I find out what part of the code within that thread is hogging the CPU? Can you recommend any debugging tools / methods that would aid in this task? If it could tell me the line(s) that are being executed the most within the program, that should be helpful.
I would like to see if I can perform optimization on the offending code, and / or see if something is not happening correctly. The process itself appears to work correctly except for the fact that it slows down and hogs the CPU more than I would think it should.
I have looked into valgrind's tools a bit, and have not been able to produce anything helpful yet (although valgrind has a lot of tools). I tried the helgrind tool so far, and have looked at http://valgrind.org/docs/manual/manual.html for further guidance. It appears the callgrind tool may be useful if I can figure out how to use it. If anyone can tell me procedurally how to do debug what portions of code are being "over utilized" with valgrind, or point me to a good resource, it would be greatly appreciated.
Use a profiler
Alternatively, you can write your own timing code, but that tends to introduce inaccuracies and false efficiencies.
There are a variety of tools that give you this information and more -- sometimes too much information. If you are working in an IA (Intel Architecture) environment, you have VTune, the Intel compiler provides a whole host of analysis tools with a variety of instrumentation overheads, and there are a lot of free and experimental tools at https://software.intel.com/en-us/whatif/. If you are on a non-IA architecture, there are a variety of compiler and other analysis tools available much better than top. There are also the various prof tools.
The IA tools from Intel can be pricey but there are various student and other discounted licenses.
I am working on a huge program that employs a (custom built) micro-threading solution. It sometimes happens that I need debug a crash. During such times, it is useful to be able to switch from one micro-thread to another.
If I'm doing live debugging, I can replace all of the registers to those that came from the micro-thread context. I have written a macro to do just that, and it works really well.
The problem is that I cannot change the register values if I am doing post-mortem debugging (from a core file). In such a case, I have no way to tell GDB to change its concept of what the current frame is, as all registers are considered read-only in that case.
Is there a way to tell GDB about my custom context management?
Shachar
There's not a simple, built-in way to do this in gdb.
I think probably the simplest way would be to write a version of gdbserver that can read your core files and that presents your micro-threads to gdb as real threads. There's been at least one gdbserver out there that can read core files already, so maybe it isn't crazily hard. However, I couldn't really say for sure.
I'm thinking about adding code to my application that would gather diagnostic information for later examination. Is there any C++ library created for such purpose? What I'm trying to do is similar to profiling, but it's not the same, because gathered data will be used more for debugging than profiling.
EDIT:
Platform: Linux
Diagnostic information to gather: information resulting from application logic, various asserts and statistics.
You might also want to check out libcwd:
Libcwd is a thread-safe, full-featured debugging support library for C++
developers. It includes ostream-based debug output with custom debug
channels and devices, powerful memory allocation debugging support, as well
as run-time support for printing source file:line number information
and demangled type names.
List of features
Tutorial
Quick Reference
Reference Manual
Also, another interesting logging library is pantheios:
Pantheios is an Open Source C/C++ Logging API library, offering an
optimal combination of 100% type-safety, efficiency, genericity
and extensibility. It is simple to use and extend, highly-portable (platform
and compiler-independent) and, best of all, it upholds the C tradition of you
only pay for what you use.
I tend to use logging for this purpose. Log4cxx works like a charm.
If debugging is what you're doing, perhaps use a debugger. GDB scripts are pretty easy to write up and use. Maintaining them in parallel to your code might be challenging.
Edit - Appending Annecdote:
The software I maintain includes a home-grown instrumentation system. Macros are used to queue log messages and configuration options control what classes of messages are logged and the level of detail to be logged. A thread processes the logging queue, flushing messages to file and rotating files as they become too large (which they commonly do). The system provides a lot of detail, but often all too often it provides huge files our support engineers must wade through for hours to find anything useful.
Now, I've only used GDB to diagnose bugs a few times, but for those issues it had a few nice advantages over the logging system. GDB scripting allowed me to gather new instrumentation data without adding new instrumentation lines and deploying a new build of my software to the client. GDB can generate messages from third-party libraries (needed to debug into openssl at one point). GDB adds no run-time impact to the software when not in use. GDB does a pretty good job of printing the contents of objects; the code-level logging system requires new macros to be written when new objects need to have their states logged.
One of the drawbacks was that the gdb scripts I generated had no explicit relationship to the source code; the source file and the gdb script were developed independently. Ideally, changes to the source file should impact and update the gdb script. One thought is to put specially-formatted comments in code and have a scripting language make a pass on the source files to generate the debugger script file for the source file. Finally, have the makefile execute this script during the build cycle.
It's a fun exercise to think about the potential of using GDB for this purpose, but I must admit that there are probably better code-level solutions out there.
If you execute your application in Linux, you can use "ulimit" to generate a core when your application crash (or assert(false), or kill -6 ), later, you can debug with gdb (gdb -c core_file binary_file) and analyze the stack.
Salu2.
PD. for profiling, use gprof
Windbg fans claim that it is quite powerful and I tend to agree. But when it comes to debugging STL containers, I am always stuck. If the variable is on the stack, the !stl extension sometimes figures it out, but when a container with a complex type (e.g. std::vector<TemplateField, std::allocator<TemplateField> >) is on the heap or part of some other structure, I just don't know how to view its contents.
Appreciate any tips, pointers.
I often find debugger support for STL data types inadequate. For this reason I'm increasingly using logging frameworks and logging statements. I used to think that these are for people who can't use a debugger, but I now realize that they offer real value. They allow you to embed portable debugging knowledge in your code and maintain it together with the code. In contrast, work you do in the debugger is typically ephemeral.
You might also want to give this debugger extension a try. It is a library called SDbgExt, developed by Skywing.
Python extension for WinDbg (pykd) have snippet stlp.py which can dump map contents.
Currently it supports STLPort map implementation. Tested on x86 and x64.
This article demonstrates how to use it (its on Russian, but, examples are self-explanatory).
I had the exact same question some time ago. My answer is that Visual Studio is truly a better debugger for STL and complex types (just like Visual Studio is just a plain better debugger than MDbg).
This is not to say WinDBG is less powerful, just that it's lower level (e.g. try doing anything useful with crash dumps using Visual Studio -- you can't).
Anyway, to answer your question, you can use Visual Studio to look at the data types using some tricks:
Start another instance of WinDBG, attach non-invasively: cdb -p <PID> -pv. This will suspend the threads of the debugee. Now you can safely detach the original WinDBG qd
Attach Visual Studio to it, and then detach the non-invasive WinDBG qd. Look at the STL and continue as you wish.
When you need to go back to WinDBG, goto step 1, swap with an invasive WinDBG.
I usually end up sticking a toString() method in a lot of my classes. This shows all the info that I deem important, any containers can then call this to display the class information in the console
Use dt -r
i.e dt yourapp!class 7ffdf000 -r5