[ext] Five Linux user space debugging Tools

There are several user-space debugging tools and techniques under Linux that are useful for analyzing user-space problems. They are:

• ' PRINT ' statement
• Inquiries (/proc,/sys, etc.)
• Tracking (Strace/ltrace)
• Valgrind (Memwatch)
• Gdb

Let's get to know each other.

1. ' PRINT ' statement

This is a basic method of the original debugging problem. We can insert print statements in the program to understand the control flow and variable values. Although this is a simple technique, it has some drawbacks. The program needs to be edited to add the ' print ' statement, which must then be recompiled and rerun to get the output. This is a time-consuming method if the program you are debugging is quite large.

2. Enquiry

In some cases, we need to figure out the state and memory mapping of a process running in the kernel. In order to obtain this information, we do not need to insert any code into the kernel. Instead, you can use the/proc file system.

/proc is a pseudo file system that collects information about the runtime system (CPU information, memory capacity, etc.) as soon as the system starts running.

Output of ' Ls/proc '

As you can see, every process running in the system has an item named after the process ID in the/proc file system. The details of each process can be obtained in a file in the directory corresponding to the process ID.

Output of ' ls/proc/pid '

Explains that all entries within the/proc file system are outside the scope of this article. Some useful examples include the following:

• /proc/cmdline, kernel command line
• /proc/cpuinfo, about the processor brand, model information, etc.
• /proc/filesystems-File system kernel support information
• /proc/<pid>/cmdline, command-line arguments passed to the current process
• /proc/<pid>/mem-The current process holds memory
• /proc/<pid>/status status of the current process

3. Tracking

Strace and Ltrace are two tracking tools used in Linux to track the execution details of a program.

Strace

Strace intercepts and records system calls and their received signals. For the user, it shows the system calls, the parameters passed to them, and the return values. Strace can be attached to a process that is already running or a new process. It is useful as a diagnostic, debugging tool for developers and system administrators. It can also be used as a tool to understand the system by tracking different program invocations. The benefit of this tool is that no source code is required and the program does not need to be recompiled.

The basic syntax for using Strace is:

Strace command

Strace have a variety of parameters. You can check Strace's hand albums to get more details.

The output of the strace is very long, and we usually don't want to be interested in each of the displayed lines. We can use the '-e expr ' option to filter unwanted data.

Use the '-P PID ' option to bind to a running process.

With the '-o ' option, the output of the command can be redirected to a file.

Strace filtered to only the output of the system call

Ltrace:

Ltrace tracks and records the invocation of a process's dynamic (runtime) library and its received signal. It can also track system calls made by a process. Its usage is similar to that of Strace.

Ltrace command

The '-i ' option prints the instruction pointer when the library is called.

The '-s ' option is used for real system calls and library calls

See the Ltrace Manual for all available options.

Ltrace capturing the output of the ' STRCMP ' library call

4. Valgrind

Valgrind is a set of debugging and analysis tools. One of its widely used default tools-' Memcheck '-can intercept malloc (), New (), free (), and delete () calls. In other words, it is useful to detect the following issues:

• Memory leaks
• Re-release
• Access out of bounds
• Use of uninitialized memory
• Use memory that has already been freed, and so on.

It runs directly through the executable file.

Valgrind also has some drawbacks because it increases the memory footprint and slows down your program. It can sometimes cause false positives and false negatives. It is not possible to detect a statically allocated array of access out-of-bounds issues.

In order to use it, please download and install it on your system first. Can be installed using the Package Manager on the operating system.

Use the command line to install a file that needs to be decompressed and unpacked for download.

1. Tar -xjvf valgring-x. Y. Z. Tar. bz2 (where x. Y. Z is the version number of trying to install)

Run the following command into the newly created directory (VALGRIND-XYZ):

1. ./Configure
2. Make
3. Make install

Let's use a small program (TEST.C) to understand how Valgrind works:

2. #include <stdio.h>
6. void f(void)
10. {
12. int x = malloc(ten * sizeof(int));
16. x[ten] = 0;
18. }
22. int main()
24. {
26. f();
28. Return 0;
30. }

Compile the program:

1. GCC -o test -g test. C

Now we have an executable file called ' test '. We can now use Valgrind to detect memory errors:

1. Valgrind –Tool=Memcheck –leak-Check=Yes Test

This is the output of the Valgrind rendering error:

Valgrind shows the output of heap overflow and memory leaks

As we saw in the above message, we are trying to access the unallocated memory of function f and allocate memory that has not yet been freed.

5. GDB

GDB is a debugger from the Free Software Foundation. It is useful for locating and fixing problems in your code. When the program being debugged runs, it gives the user control to perform various actions, such as:

• Start the program
• Stop at the specified location
• Stop in the specified condition
• Check the required information
• Change the data in the program and so on.

You can also attach a crashed program coredump to GDB and analyze the cause of the failure.

GDB offers many options to debug a program. However, we will introduce some important options to feel how to get started with GDB.

If you have not yet installed GDB, you can download it here: GDB official website.

Compile the program:

In order to debug a program with GDB, you must compile with the '-G ' option of GCC. This produces debug information in the local format of the operating system, and GDB uses this information to work.

The following is a simple program (example1.c) performed by 0 except to show GDB's usage:

2. #include
4. int divide()
6. {
8. int x=5, y=0;
10. return x / y;
12. }
16. int main()
18. {
20. Divide();
22. }

Show examples of GDB usage

Call GDB:

Start gdb by executing ' gdb ' on the command line:

Call GDB

After it is called, it waits for the terminal command and executes until it exits.

If a process is already running, you need to connect gdb to it, which can be implemented by specifying the process ID. Assuming the program has crashed, to analyze the cause of the problem, use GDB to analyze the core file.

Start the program:

Once you are inside GDB, use the ' run ' command to start the program for debugging.

To pass parameters to the program:

Use ' Set args ' to pass parameters to your program, which will be obtained the next time the program runs. ' Show args ' will display the parameters passed to the program.

To check the stack:

Whenever the program stops, the first thing anyone wants to understand is why it stopped and how it stopped there. This information is referred to as a reverse trace. Generated by the program each function call and local variables, passing parameters, call location and other information stored together in the stack of data block species, is called a frame. We can use GDB to check all this data. GDB numbers these frames starting at the bottom of the frame.

• BT: Print the entire stack's backtracking
• bt Print N-Frames backtracking
• Frame: Switch to the specified frame and print the frame
• up: Move Up ' n ' frames
• down: Move Down ' n ' frames (n default is 1)

Check data:

The program's data can be checked inside gdb using the ' print ' command. For example, if ' x ' is a variable within a debugger, ' Print x ' prints the value of x.

Check the source code:

The source code can be printed in gdb. By default, the ' list ' command prints 10 lines of code.

• list : List The source code around the ' LineNum ' line
• list : Start listing the source code from ' function '
• Disas : Show the function machine code

Stopping and recovering programs:

Using GDB, we can set breakpoints, observation points and so on where necessary to stop the program.

• Break: Set a breakpoint at ' location '. When the program executes here, the breakpoint is hit and the control is handed over to the user.
• Watch : gdb stops when ' expr ' is written by the program and its value changes
• catch : GdB stops when ' event ' occurs
• Disable : Disables the specified breakpoint
• enable: Enables the specified breakpoint
• Delete: Deletes the breakpoint/observer/capture point. If no parameters are passed the default action is at all breakpoints
• Step: Steps to execute a program
• continue: Continue executing the program until execution is complete

Exit GDB:

The ' Quit ' command also exits from GDB.

GDB also has more options available. Inside, GDB uses the Help option to learn more details.

Get help in GdB

Summarize

In this article, we've seen debugging tools for different types of Linux user space. To summarize all of the above, here is a quick guide on when to use this:

• Basic debug, Get key variable-print statement
• Get information about file system support, available memory, CPU, kernel status of running programs-querying the/proc file system
• Initial problem diagnosis, system call or library call related issues, understanding program flow –strace/ltrace
• Application memory Space Problem –valgrind
• Examine the behavior of the application runtime and analyze the application crash –gdb

[Goto] Five Linux user space debugging Tools