What kind of debugging tools you've been using to debug working binaries?
Is there are debugging toolkits in addition to GDB?
The only reason is that I'm quite new for system debugging and I've been debugging my system service.
Sultan
I'd recommend Valgrind [1]. It's quite useful when dealing with memory leaks and segfaults.
The segfaults can be tracked by letting GDB run (without any breakpoint) and check the backtrace ('bt' command), after the crash.
P.S.: I don't remember if Valgrind is avaliable for other systems, but since you asked about alternatives to GDB, I'm assuming you're on a *nix box.
Have a nice debugging.
[1] http://valgrind.org/
Assuming you are on Linux systems, one of the most valuable tool is valgrind.
I don't really use anything else except for precondition/postcondition check in the code itself (i.e. assertion on methods' input values).
Related
I installed LiteIDE and GDB. I opened my Go project in LiteIDE and added a breakpoint to some point in the code. Then i switched back to terminal and ran the project binary that was supposed to envoke the breakpoint and nothing happened. What am i doing wrong?
You have to actually launch the executable from the IDE for breakpoints to mean anything.
Also keep in mind that gdb is mostly meaningless with Go 1.3.x and even more so with 1.4 (dev).
From https://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success.
In time, a more Go-centric debugging architecture may be required.
I use this package https://github.com/gostart/debug/ and so far it is the best solution that I have found.
Hope this helps.
I am very interested in learning more about the specifics of debugging, and I am looking into making a very simple GUI for debugging with GDB.
I understand in general how debuggers work, but I am having trouble of how an IDE interacts with an external debugger like GDB.
I am sure I could call commands to setup breakpoints and such in the debugger, but I am unsure of how an IDE would get the information back like, oh the breakpoint you set has been hit or variable values and such. Is there good information of using GDB within another program, I tried searching google, but all results I get are about how to debug another program using GDB or setting it up in a IDE already developed.
does it involve hooking into GDB? or does GDB have a library?
Thanks.
does it involve hooking into GDB? or does GDB have a library?
No and no.
GDB has a machine interface, intended for interfacing between and IDE and GDB.
How are operating systems typically debugged? They cannot be stepped through with a debugger like simple console programs, and the build times are too large to repeatedly make small changes and recompile the whole thing.
They aren't debugged as a multi-gigabyte programs! :)
If you mean the individual user-mode components, they can mainly be debugged just like normal programs and libraries (because they are normal programs/libraries!).
For kernel-mode components, though, each OS has its own mechanism; here is some information regarding the way that we do kernel debugging in Windows. It can be done using the help of another machine connected to the machine you're debugging, via a serial port or something. I'm not familiar with the process itself, but that's the gist of how they work. (You need to set some boot loader options so that the system is ready for the debugger to be connected as early as possible.)
It depends on which part of the operating system you're talking about. When I worked at MSFT, I worked on the IE team. We debugged IE and the shell (Windows Explorer) in Visual Studio and stepped through them line by line all day long. Though, sometimes, it's easier to debug using a command line tool such as NTSD.
If, however, you want to debug anything in Kernel land such as the OS kernel or device drivers, which I suspect is really what you're asking, then you must use the Kernel debugger. For Windows that is a command line tool called kd, and generally you run the debugger on one machine and remotely debug the target.
There are a whole set of techniques throughout history from flashing lights on the console, to the use of hardware devices like an ICE, to more modern techniques utilizing fairly standard debuggers. One technique that is more common among OS developers then application developers is the analysis of a core dump. Look at something like mdb on solaris for ideas about how Solaris kernel developers do some of their debugging. Also tracing technologies are used. Anywhere from fairly straightforward logging packages to more modern techniques like dtrace.
Also note that the techniques used depend on the layer of software. Initial boot tends to be a fairly hard place to get your fingers into. But after that the environment of modern operation systems looks more and more like the application setting you are use to. In the end, it is all code :)
I have MPI program which I want to debug.
I use mpich 2 under Windows, so does anybody know tools that can help me? Is it even possible?
I have some experience of the parallel debuggers DDT and Totalview on Linux. I see that DDTLite is available as a plug-in for MS Visual Studio; I don't think that there is a version of Totalview for any Windows platform.
So, yes, it is possible, but DDTLite costs money; however I couldn't work without either DDT or Totalview.
It's possible that Microsoft, who now produce an HPC edition of Windows, have parallelised their debugger but I have no knowledge of that. You can use gdb on parallel programs, so an installation under Cygwin (or similar) might help you. Personally I have never found gdb for parallel debugging anything other than incredibly difficult and I am fortunate to work at a site where getting a parallel debugger has not proven difficult.
Preferably from Ubuntu repositories.
Others have mentioned OProfile; for full-system statistical profiling on modern Linux installations, it does indeed rock.
The more venerable tool (which doesn't require kernel support and thus will work under older versions of Linux or even non-Linux operating systems) is GNU gprof, included in binutils (and thus doubtless already installed in your development environment).
To use gprof, just compile your application with the -pg argument to gcc; a file called gmon.out will be created after your program exits, and gprof can then be used to analyze this file.
A simple but effective technique is to run the program under GDB and handle the SIGINT signal. While the program is running, generate SIGINT manually by typing control-c or whatever, and while it is halted, record the call stack. Do this a number of times, like 10 or 20, while the program is being subjectively slow. This will give you a very good idea of where the time goes.
This method does not give you precise timing, but it does precisely locate the instructions, including call instructions, that cost the most time.
How can I profile C++ code running in Linux?
Sysprof is a good profiler, similar to OProfile (also has a gtk GUI). which is available in the Ubuntu repository. It's a kernel level profiler, requiring a kernel module unlike gprof, however, also unlike gprof, it can profile multithreaded applications.
There is OProfile. It is not that difficult to use, but is somewhat buggy.
I've had good success with oprofile (http://oprofile.sourceforge.net/news/) which is available in Ubuntu repositories as well. It doesn't require recompilation, and doesn't have any limitations regarding shared objects or the like.