| |
By definition, debugging tools are those that allow us to monitor, control and other procedures to correct the program. Why should we use the debugging tool? In some cases, applications that run when we get stuck, we need to understand what happened. For example, we are running an application, it generates some error messages. To fix these errors, we should first find out why these error messages generated and where these error messages generated. An application may abruptly suspended, we must understand what other processes running simultaneously. What we may also have to figure out a process hangs when doing. To analyze these details, we need to help debug tools.
There are several Linux user space under debugging tools and techniques that are used to analyze problems of user-space quite useful. They are:
'Print' statement
Query (/ proc, / sys, etc.)
Tracking (strace / ltrace)
Valgrind (memwatch)
GDB
Let us understand one by one.
1.'print 'statement
This is a fundamental primitive debugging problems. We can insert print statements in your program to understand the control flow and variable values. Although this is a simple technique, but it has some drawbacks. Programs need to be edited to add the 'print' statement, then you must recompile, re-run to obtain the output. If you are debugging a program is quite large, it is a time-consuming method.
2. Query
In some cases, we need to figure out in a running process in the kernel status and memory mapping. To obtain this information, we do not need to insert any code in the kernel. Instead, you can use the / proc filesystem.
/ Proc is a pseudo file system, a system up and running the collection of information (cpu information, memory capacity, etc.) runtime system.
As you can see, each process running on the system has a process id named entry in the / proc file system. Detailed information about each process can be obtained in the process id corresponding file directory under.
All entry explains the / proc file system is beyond the scope of this article. Some useful are listed below:
/ Proc / cmdline -> kernel command line
/ Proc / cpuinfo -> brand, model and other information about the processor
/ Proc / filesystems -> file system kernel support information
/ Proc / / cmdline -> command line arguments passed to the current process
/ Proc / / mem -> memory holds the current process
/ Proc / / status -> state of the current process
3. Tracking
strace and ltrace are two procedures used to track the implementation details of the tracking tool in Linux.
strace:
strace interception and recording system calls and received signals. For users, it shows the system call is passed to their parameters and return values. strace can be attached to an already running process or a new process. It acts as a diagnostic and debugging tool for developers and system administrators are very useful. It is also used as a different program by tracking calls to understand the system tools. The advantage of this tool is that no source code, the program does not need to be recompiled.
Use strace basic syntax is:
strace command
strace has a variety of parameters. You can check to see strace man page for more details.
strace output is very long, we do not normally show interest in each row. We can filter unwanted data '-e expr' option.
With '-p pid' option to bind to a running process.
With '-o' option, the command output can be redirected to a file.
strace filter to output system calls only
ltrace:
Ltrace dynamic tracking and recording of a process (run-time) signal library calls and received. It can also track the system calls made by a process. Its usage is similar to strace.
ltrace command
'-i' Option to print the instruction pointer when calling the library.
'-S' Option is used to the reality of system calls and library calls
See all available options ltrace manual.
Output trace capture 'STRCMP' library call
4. Valgrind
Valgrind is a set of debugging and analysis tools. It's a default tools are widely used - 'Memcheck' - can block malloc (), new (), free () and delete () call. In other words, it is very useful to detect the following problems:
Memory leak
? Re-release
Access violation
Uninitialized memory
Use has been released memory.
It is run directly by the executable file.
Valgrind also has some disadvantages, because it increases the memory footprint, will slow down your program. It can sometimes cause false positives and false negatives. Access to it can not be detected statically allocated array of cross-border issues.
To use it, first download and install on your system. You can use the package manager to install the operating system.
Using the command line to install unzip and unpack the downloaded file.
tar -xjvf valgring-x.y.z.tar.bz2 (where x.y.z is the version number you are trying to install)
Into the newly created directory (in valgrind-XYZ), run the following command within:
./configure
make
make install
Let's go through a small program (test.c) valgrind to understand how it works:
#include
void f (void)
{
int x = malloc (10 * sizeof (int));
x [10] = 0;
}
int main ()
{
F. ();
return0;
}
Compiler:
gcc -o test -g test.c
Now we have an executable file named 'test'. We can now use valgrind to detect memory errors:
valgrind -tool = memcheck -leak-check = yes test
This is valgrind rendered incorrect output:
valgrind show heap overflows and memory leaks output
As we have seen above the message we're trying to access the function f unallocated memory and memory allocation not yet released.
5. GDB
GDB is a debugger from the Free Software Foundation. It helps to locate and fix problems in the code. When the program being debugged is running, it gives the user control to perform various actions, such as:
starting program
Park in a position
Parked in the specified conditions
Check the required information
Changing the program data.
You can also be a crash program coredump attached to GDB and Failure Analysis.
GDB debugger offers many options. However, we will introduce some important choices to feel how to start using GDB.
If you have not installed GDB, can be downloaded here: GDB official website.
Compiler:
To use GDB debugger, you must use the gcc '-g' option to compile. This will generate debugging information operating system's native format, GDB use the information to work.
Here is a simple program (example1.c) execution is zero for displaying GDB usage:
#include
int divide ()
{
int x = 5, y = 0;
return x / y;
}
int main ()
{
divide ();
}
GDB example shows usage
Call GDB:
By performing 'gdb' at the command line to start gdb:
Call gdb
After the call, it waits for the terminal command and execution, until you exit.
If a process is already running, you will need to GDB connected to it, can be achieved by specifying the process ID. Assume that the program has crashed due to analyze the problem, analyze the core file with GDB.
starting program:
Once you are inside GDB, use the 'run' command to start the program for debugging.
Pass parameters to the program:
Use 'set args' pass parameters to your program, when the program is next run will get the argument. 'Show args' will display the parameters passed to the program.
Check the Stack:
Whenever the program is stopped, anyone who wants to understand why the first thing is to stop it, and how to stop there. This information is called backtracking. Each function call is generated by the program and local variables, parameters passed, call location information is stored together in a stack of data in the block is called a. We can use GDB to check all the data. GDB start from the bottom of the frame to the frame number.
bt: print the entire stack traceback
bt Print n frames back
frame: Switch to a specified frame, the frame and print
Move 'n' frames on: up
down: Down 'n' frames (n default is 1)
Check the data:
Data programs can use GDB 'print' command inside to be checked. For example, if 'x' is a variable within the debugger, 'print x' will print the value of x.
Check the source code:
Source code can be printed in GDB. By default, 'list' command will print 10 lines of code.
list: Lists 'linenum' line around the source
list: From the 'function' start listing source
disas: This function displays the machine code
Stop and recovery procedures:
Use GDB, we can set breakpoints, watch points, etc. where necessary to stop the program.
break: In the 'location' to set a breakpoint. When the program execution to the breakpoint will be hit here, control was handed over to the user.
watch: when 'expr' is written in the program and its value changes when GDB stops
catch: When the 'event' occurs GDB stop
disable: Disable the specified breakpoints
enable: Enable the specified breakpoints
delete: delete a breakpoint / watchpoint / capture points. If you do not pass parameters to the default action is all breakpoints
step: step by step execution
continue: to continue the program until completed
Quit GDB:
With the 'quit' command also exit from GDB.
GDB There are more options available. Inside GDB use help option for more details.
Getting Help in GDB
to sum up
In this article, we have seen different types of Linux user space debugging tools. Summarize all of the above, the following is what when to use the quick guide:
Basic commissioning, access to key variables - print statement
Obtain information about the file system support, available memory, CPU, run the program kernel status information - Discover / proc filesystem
Issues related to the initial problem diagnosis, system calls or library calls, to understand the program flow - strace / ltrace
Problems application memory space - valgrind
Check the behavior of the application is running, analyzes application crashes - gdb |
|
|
|