mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-22 23:00:57 +08:00
Merge pull request #2171 from mtunique/master
【翻译完成】20141229 5 User Space Debugging Tools in Linux
This commit is contained in:
Xingyu.Wang
commit
38fb9e504c
@ -1,265 +0,0 @@
|
||||
translating by mtunique
|
||||
5 User Space Debugging Tools in Linux
|
||||
================================================================================
|
||||
By definition, debugging tools are those programs which allow us to monitor ,control and correct errors in other programs while they execute. Why should we use debugging tools? To answer this, there are various situations where we get stuck while running some programs and will have the need to understand what exactly happened. For example, we might be running an application and it produces some error messages. To fix those errors, we should first figure out why and from where did the error messages come from. An application might suddenly hang and we will have to know what other processes were running at that time. We might also have to figure out what was process 'x' doing at the time of hang. In order to dissect such details, we will need the help of debugging tools. There are a few user space debugging tools and techniques in Linux which are quite useful in analysing user space problems. They are:
|
||||
|
||||
- **'print' statements**
|
||||
- **Querying (/proc, /sys etc)**
|
||||
- **Tracing (strace/ltrace)**
|
||||
- **Valgrind (memwatch)**
|
||||
- **GDB**
|
||||
|
||||
Let's go through each of them one by one.
|
||||
|
||||
### 1.'print' statements ###
|
||||
|
||||
This is a basic or primitive way of debugging a problem. We can insert print statements in the middle of a program to understand the control flow and get the value of key variables. Though it is a simple technique, it has some disadvantages to it. Programs need to be edited to add 'print 'statements which then will have to be recompiled and rerun to get the output. This is a time-consuming method if the program to be debugged is quite big.
|
||||
|
||||
### 2. Querying ###
|
||||
|
||||
In some situations, we might want to figure out in what state a running process is in the kernel or what is the memory map that it is occupying there etc. In order to obtain this type of information, we need not insert any code into the kernel. Instead, one can use the /proc filesystem.
|
||||
|
||||
/proc is a pseudo filesystem that gets populated with runtime system information (cpu information, amount of memory etc) once the system is up and running.
|
||||
|
||||
|
||||
output of 'ls /proc'
|
||||
|
||||
As you can see, each process that is running in the system has an entry in the /proc filesystem in the form of its process id . Details about each of these processes can be obtained by looking into the files present in its process id directory
|
||||
|
||||
|
||||
output of 'ls /proc/pid'
|
||||
|
||||
Explaining all the entries inside the /proc filesystem is beyond the scope of this document. Some of the useful ones are listed below:
|
||||
|
||||
- /proc/cmdline -> Kernel command line
|
||||
- /proc/cpuinfo -> information about the processor's make, model etc
|
||||
- /proc/filesystems -> filesystem information supported by the kernel
|
||||
- /proc//cmdline -> command line arguments passed to the current process
|
||||
- /proc//mem -> memory held by the process
|
||||
- /proc//status -> status of the process
|
||||
|
||||
### 3. Tracing ###
|
||||
|
||||
strace and ltrace are two of the tracing tools used in Linux to trace program execution details.
|
||||
|
||||
#### strace: ####
|
||||
|
||||
strace intercepts and records system calls within a process and the signals received by it. To the user, it displays the system calls, arguments passed to them and the return values. strace can be attached to a process that is already running or to a new process. It is useful as a diagnostic and debugging tools for developers and system administrators. It can also be used as a tool to understand how system calls work by tracing different programs. Advantage of this tool is that no source code is needed and programs need not be recompiled.
|
||||
|
||||
The basic syntax for using strace is:
|
||||
|
||||
**strace command**
|
||||
|
||||
There are various options that are available to be used with strace command. One can check out the man page for strace tool to get more details.
|
||||
|
||||
The output of strace can be quite lengthy and we may not be interested in going through each and every line that is displayed. We can use the '-e expr' option to filter the unwanted data.
|
||||
|
||||
Use '-p pid' option to attach it to a running process.
|
||||
|
||||
Output of the command can be redirected to a file using the '-o' option
|
||||
|
||||
|
||||
output of strace filtering only the open system call
|
||||
|
||||
#### ltrace: ####
|
||||
|
||||
ltrace tracks and records the dynamic (runtime) library calls made by a process and the signals received by it. It can also track the system calls made within a process. It's usage is similar to strace
|
||||
|
||||
**ltrace command**
|
||||
|
||||
'-i ' option prints the instruction pointer at the time of library call
|
||||
|
||||
'-S' option is used to display both system calls and library calls
|
||||
|
||||
Refer to the ltrace man page for all the available options.
|
||||
|
||||
|
||||
output of ltrace capturing 'strcmp' library call
|
||||
|
||||
### 4. Valgrind ###
|
||||
|
||||
Valgrind is a suite of debugging and profiling tools. One of the widely used and the default tool is a memory checking tool called 'Memcheck' which intercepts calls made to malloc(), new(), free() and delete(). In other words, it is useful in detecting problems like:
|
||||
|
||||
- memory leaks
|
||||
- double freeing
|
||||
- boundary overruns
|
||||
- using uninitialized memory
|
||||
- using a memory after it has been freed etc.
|
||||
|
||||
It works directly with the executable files.
|
||||
|
||||
Valgrind comes with a few drawbacks as well. It can slow down your program as it increases the memory footprint. It can sometimes produce false positives and false negatives. It cannot detect out-of-range access to statically allocated arrays
|
||||
|
||||
In order to use it, first download it and install it on your system. ([Valgrind's download page][1]). It can be installed using the package manager for the operating system that one is using.
|
||||
|
||||
Installation using command line involves decompressing and untarring the downloaded file.
|
||||
|
||||
tar -xjvf valgring-x.y.z.tar.bz2 (where x.y.z is the version number you are trying to install)
|
||||
|
||||
Get inside the newly created directory (valgrind-x.y.z)and run the following commands:
|
||||
|
||||
./configure
|
||||
make
|
||||
make install
|
||||
|
||||
Let's understand how valgrind works with a small program(test.c):
|
||||
|
||||
#include <stdio.h>
|
||||
|
||||
void f(void)
|
||||
|
||||
{
|
||||
int x = malloc(10 * sizeof(int));
|
||||
|
||||
x[10] = 0;
|
||||
}
|
||||
|
||||
int main()
|
||||
{
|
||||
f();
|
||||
return 0;
|
||||
}
|
||||
|
||||
Compile the program:
|
||||
|
||||
gcc -o test -g test.c
|
||||
|
||||
Now we have an executable file called 'test'. We can now use valgrind to check for memory errors:
|
||||
|
||||
valgrind –tool=memcheck –leak-check=yes test
|
||||
|
||||
Here is the valgrind output showing the errors:
|
||||
|
||||
|
||||
output of valgrind showing heap block overrun and memory leak
|
||||
|
||||
As we can see in the above message, we are trying to access the area beyond what is allocated in function f and the allocated memory is not freed.
|
||||
|
||||
### 5. GDB ###
|
||||
|
||||
GDB is a debugger from Free Software Foundation. It is useful in locating and fixing problems in the code. It gives control to the user to perform various actions when the program to be debugged is running, like:
|
||||
|
||||
- starting the program
|
||||
- stop at specified locations
|
||||
- stop on specified conditions
|
||||
- examine required information
|
||||
- make changes to data in the program etc.
|
||||
|
||||
One can also attach a core dump of a crashed program to GDB and analyse the cause of crash.
|
||||
|
||||
GDB provides a lot of options to debug programs. However, we will cover some important options here so that one can get a feel of how to get started with GDB.
|
||||
|
||||
If you do not already have GDB installed, it can be downloaded from [GDB's official website][2].
|
||||
|
||||
#### Compiling programs: ####
|
||||
|
||||
In order to debug a program using GDB, it has to be compiled using gcc with the'-g' option. This produces debugging information in the operating system's native format and GDB works with this information.
|
||||
|
||||
Here is a simple program (example1.c)performing divide by zero to show the usage of GDB:
|
||||
|
||||
#include
|
||||
int divide()
|
||||
{
|
||||
int x=5, y=0;
|
||||
return x / y;
|
||||
}
|
||||
|
||||
int main()
|
||||
{
|
||||
divide();
|
||||
}
|
||||
|
||||
|
||||
An example showing usage of gdb
|
||||
|
||||
#### Invoking GDB: ####
|
||||
|
||||
GDB can be started by executing 'gdb' in the command-line:
|
||||
|
||||
|
||||
invoking gdb
|
||||
|
||||
Once invoked, it remains there waiting for commands from the terminal and executing them until exited .
|
||||
|
||||
If a process is already running and you need to attach GDB to it, it can be done by specifying the process id Suppose a program has already crashed and one wants to analyse the cause of the problem, then attaching GDB to the core file helps.
|
||||
|
||||
#### Starting the program: ####
|
||||
|
||||
Once you are inside GDB, use the 'run' command to start the program to be debugged
|
||||
|
||||
#### Passing arguments to the program: ####
|
||||
|
||||
Use the 'set args' command to send the arguments to your program when it runs next time 'show args' will show the arguments passed to the program
|
||||
|
||||
#### Verifying the stack: ####
|
||||
|
||||
Whenever a program stops, first thing anyone wants to understand is why it stopped and how it stopped there. This information is called backtrace. Every function call generated by a program gets stored along with the local variables, arguments passed, call location etc in a block of data inside the stack and is called a frame. Using GDB we can examine all this data. GDB identifies these frames by giving them numbers starting from the innermost frame.
|
||||
|
||||
- **bt**: prints the backtrace of the entire stack
|
||||
- **bt <n>** prints the backtrace of n frames
|
||||
- **frame <frame number>**: switches to the specified frame and prints that frame
|
||||
- **up <n>**: move 'n' frames up
|
||||
- **down <n>**: move 'n' frames down. ( n is 1 by default)
|
||||
|
||||
#### Examining data: ####
|
||||
|
||||
Program's data can be examined inside GDB using the 'print' command. For example, if 'x' is a variable inside the debugging program, 'print x' prints the value of x.
|
||||
|
||||
#### Examining source: ####
|
||||
|
||||
Parts of source file can be printed within GDB. 'list' command by default prints 10 lines of code.
|
||||
|
||||
- **list <linenum>**: list the source file around 'linenum'
|
||||
- **list <function>**: list the source from the beginning of 'function'
|
||||
|
||||
- **disas <function>**: displays the machine code for the function
|
||||
|
||||
#### Stopping and resuming the program: ####
|
||||
|
||||
Using GDB, we can set breakpoints, watchpoint etc in order to stop the program wherever required.
|
||||
|
||||
- **break <location>**: Sets up a breakpoint at 'location'. When this is hit while the program is executing, control is given to the user.
|
||||
- **watch <expr>**: GDB stops when the 'expr' is written into by the program and it's value changes
|
||||
- **catch <event>**: GDB stops when the 'event' occurs.
|
||||
- **disable <breakpoint>**: disable the specified breakpoint
|
||||
- **enable <breakpoint>**: enable the specified breakpoint
|
||||
- **delete <breakpoint>**: delete the breakpoint / watchpoint / catch point passed. If no arguments are passed default action is to work on all the breakpoints
|
||||
|
||||
- **step**: execute the program step by step
|
||||
- **continue**: continue with program execution until execution is complete
|
||||
|
||||
#### Exiting GDB: ####
|
||||
|
||||
Use the 'quit' command to exit from GDB
|
||||
|
||||
There are many more options that are available with GDB. Use the help option once you are inside GDB for more details.
|
||||
|
||||
|
||||
getting help within gdb
|
||||
|
||||
### Summary ###
|
||||
|
||||
In this article, we have seen different types of user space debug tools available in Linux. To summarise all of them, here is a quick guideline on when to use what:
|
||||
Basic debugging, getting values of key variables – print statements
|
||||
|
||||
Get information about filesystems supported, available memory, cpus, status of a running program in the kernel etc - querying /proc filesystem
|
||||
|
||||
Initial problem diagnosis, system call or library call related issues , understanding program flow – strace / ltrace
|
||||
|
||||
Application space related memory problems – valgrind
|
||||
|
||||
To examine runtime behaviour of applications, analysing application crashes – gdb.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-how-to/user-space-debugging-tools-linux/
|
||||
|
||||
作者：[B N Poornima][a]
|
||||
译者：[mtunique](https://github.com/mtunique)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://linoxide.com/author/bnpoornima/
|
||||
[1]:http://valgrind.org/downloads.html
|
||||
[2]:http://www.gnu.org/software/gdb/download/
|
||||
@ -0,0 +1,263 @@
|
||||
5 Linux下用户空间调试工具
|
||||
================================================================================
|
||||
根据定义，调试工具是那些那些使我们能够监测、控制和纠正其他程序的程序。我们为什么应该用调试工具呢? 在有些情况下，运行一些程序的时候我们会被卡住，我们需要明白究竟发生了什么。 例如, 我们正在运行应用程序，它产生了一些错误消息。要修复这些错误，我们应该先找出为什么产生这些错误的消息和这些错误消息从哪里产生的。 一个应用程序可能突然挂起，我们必须了解其他什么进程同时在运行。我们可能还必须弄清楚进程'x'挂起的时候在做什么。为了剖析这些细节， 我们需要调试工具的帮助。有几个Linux下的用户空间调试工具和技术，他们用来分析用户空间问题相当有用。他们是:
|
||||
|
||||
- **'print' 语句**
|
||||
- **查询 (/proc, /sys etc)**
|
||||
- **跟踪 (strace/ltrace)**
|
||||
- **Valgrind (memwatch)**
|
||||
- **GDB**
|
||||
|
||||
让我们一个个地了解。
|
||||
|
||||
### 1.'print' 语句 ###
|
||||
|
||||
这是一个基本的原始的调试问题的方法。 我们可以在程序中插入print语句来了解控制流和变量值。 虽然这是一个简单的技术, 但它有一些缺点的。 程序需要进行编辑以添加'print'语句，然后不得不重新编译，重新运行来获得输出。 如果要调试的程序相当大，这是一个耗时的方法。
|
||||
|
||||
### 2. 查询 ###
|
||||
|
||||
在某些情况下，我们需要弄清楚在一个运行在内核中的进程的状态和内存映射。为了获得这些信息，我们不需要在内核中插入任何代码。 相反，可以用 /proc 文件系统。
|
||||
|
||||
/proc 是一个伪文件系统，系统一起启动运行就收集着运行时系统的信息 (cpu信息, 内存容量 等)。
|
||||
|
||||
|
||||
'ls /proc'的输出
|
||||
|
||||
正如你看到的, 系统中运行的每一个进程在/proc文件系统中有一个以进程id命名的项。每个进程的细节信息可以在进程id对应的目录下的文件中获得。
|
||||
|
||||
|
||||
'ls /proc/pid'的输出
|
||||
|
||||
解释/proc文件系统内的所有条目超出了本文的范围。一些有用的列举如下：
|
||||
|
||||
- /proc/cmdline -> 内核命令行
|
||||
- /proc/cpuinfo -> 关于处理器的品牌，型号信息等
|
||||
- /proc/filesystems -> 文件系统的内核支持的信息
|
||||
- /proc//cmdline -> 命令行参数传递到当前进程
|
||||
- /proc//mem -> 当前进程持有的内存
|
||||
- /proc//status -> 当前进程的状态
|
||||
|
||||
### 3. 跟踪 ###
|
||||
|
||||
strace的和ltrace是两个在Linux中用来追踪程序的执行细节的跟踪工具
|
||||
|
||||
#### strace: ####
|
||||
|
||||
strace拦截和记录系统调用并且由它来接收的信号。对于用户，它显示了系统调用，传递给它们的参数和返回值。 strace的可以附着到已在运行的进程中，或到一个新的进程。它作为一个针对开发者和系统管理员的诊断，调试工具是很有用的。它也可以用来当为一个通过跟踪不同的程序调用来了解系统的工具。这个工具的好处是不需要源代码和程序不需要重新编译。
|
||||
|
||||
使用strace的基本语法是：
|
||||
|
||||
**strace command**
|
||||
|
||||
strace有各种各样的参数。可以检查看strace的手册页来获得更多的细节。
|
||||
|
||||
strace的输出非常长，我们通常不会对显示的每一行都感兴趣。我们可以用'-e expr'选项来过滤不想要的数据。
|
||||
|
||||
用 '-p pid' 选项来绑到运行中的进程.
|
||||
|
||||
用'-o'选项，命令的输出可以被重定向到文件。
|
||||
|
||||
|
||||
strace过滤成只有系统调用的输出
|
||||
|
||||
#### ltrace: ####
|
||||
|
||||
ltrace跟踪和记录一个进程的动态（运行时）库的调用和收到的信号。它也可以跟踪一个进程所作的系统调用。它的用法是类似与strace。
|
||||
|
||||
**ltrace command**
|
||||
|
||||
'-i' 选项在调用库时打印指令指针。
|
||||
|
||||
'-S' 选项被用来现实系统调用和库调用
|
||||
|
||||
所有可用的选项请参阅ltrace手册。
|
||||
|
||||
|
||||
ltrace捕捉'STRCMP'库调用的输出
|
||||
|
||||
### 4. Valgrind ###
|
||||
|
||||
Valgrind是一套调试和分析工具。一个被广泛使用的工具，默认的工具被称为'Memcheck'的拦截malloc()，new()，free()和delete()调用的内存检测工具。换句话说，它在检测下面这些问题非常有用：
|
||||
|
||||
- 内存泄露
|
||||
- 重释放
|
||||
- 访问越界
|
||||
- 使用未初始化的内存
|
||||
- 使用的内存已经被释放 等。
|
||||
|
||||
它直接通过可执行文件运行。
|
||||
|
||||
Valgrind带有一些缺点。因为它增加了内存占用，可以减慢你的程序。它有时会造成误报和漏报。它不能检测出静态分配的数组的访问越界问题。
|
||||
|
||||
为了用他， 首先下载并安装在你的系统上。 ([Valgrind下载页面][1]). 可以使用操作系统上的包管理起来安装。
|
||||
|
||||
使用命令行安装涉及解压缩，解包下载的文件。
|
||||
|
||||
tar -xjvf valgring-x.y.z.tar.bz2 (where x.y.z is the version number you are trying to install)
|
||||
|
||||
进入新创建的目录（的valgrind-XYZ）内运行以下命令：
|
||||
|
||||
./configure
|
||||
make
|
||||
make install
|
||||
|
||||
让我们通过一个小程序(test.c)来理解valgrind怎么工作的:
|
||||
|
||||
#include <stdio.h>
|
||||
|
||||
void f(void)
|
||||
|
||||
{
|
||||
int x = malloc(10 * sizeof(int));
|
||||
|
||||
x[10] = 0;
|
||||
}
|
||||
|
||||
int main()
|
||||
{
|
||||
f();
|
||||
return 0;
|
||||
}
|
||||
|
||||
编译程序:
|
||||
|
||||
gcc -o test -g test.c
|
||||
|
||||
现在我们有一个可执行文件叫做'test'。我们现在可以用valgrind来检测内存错误：
|
||||
|
||||
valgrind –tool=memcheck –leak-check=yes test
|
||||
|
||||
这是valgrind呈现错误的输出：
|
||||
|
||||
|
||||
valgrind显示堆溢出和内存泄漏的输出
|
||||
|
||||
正如我们在上面看到的消息，我们正在试图访问超出函数f分配的内存和分配的内存没有释放。
|
||||
|
||||
### 5. GDB ###
|
||||
|
||||
GDB是来自自由软件基金会的调试器。它对定位和修复代码中的问题很有帮助。当被调试的程序运行时，它给用户控制权去执行各种动作， 比如:
|
||||
|
||||
- 启动程序
|
||||
- 停在指定位置
|
||||
- 停在指定的条件
|
||||
- 检查所需信息
|
||||
- 改变程序中的数据 等。
|
||||
|
||||
你也可以附加一个崩溃的程序coredump到GDB并分析故障的原因。
|
||||
|
||||
GDB提供很多选项来调试程序。 然而，我们将介绍一些重要的选择，来感受如何开始使用GDB。
|
||||
|
||||
如果你还没有安装GDB，可以在这里下载 [GDB官方网站][2].
|
||||
|
||||
#### 编译程序: ####
|
||||
|
||||
为了用GDB调试程序，必须使用gcc的'-g'选项进行编译。将以操作系统的本地格式产生调试信息，GDB利用这些信息来工作。
|
||||
|
||||
下面是一个简单的程序（example1.c）执行被零除用来显示GDB的用法:
|
||||
|
||||
#include
|
||||
int divide()
|
||||
{
|
||||
int x=5, y=0;
|
||||
return x / y;
|
||||
}
|
||||
|
||||
int main()
|
||||
{
|
||||
divide();
|
||||
}
|
||||
|
||||
|
||||
展示GDB用法的例子
|
||||
|
||||
#### 调用 GDB: ####
|
||||
|
||||
通过在命令行中执行'gdb'来启动gdb:
|
||||
|
||||
|
||||
调用 gdb
|
||||
|
||||
一旦调用, 它将等待终端命令并执行，直到退出。
|
||||
|
||||
如果一个进程已经在运行，你需要将GDB连接到它上面，可以通过指定进程ID来实现。假设程序已经崩溃，要分析问题的原因，则连接GDB到core文件。
|
||||
|
||||
#### 启动程序: ####
|
||||
|
||||
一旦你在GDB里面，使用'run'命令来启动程序进行调试。
|
||||
|
||||
#### 给程序传参数: ####
|
||||
|
||||
使用'set args'给你的程序传参数，当程序下次运行时将获得参数。'show args'将显示传递给程序的参数。
|
||||
|
||||
#### 检查堆栈: ####
|
||||
|
||||
每当程序停止，任何人想明白的第一件事就是它为什么停止，以及怎么停在那里的。该信息被称为反向跟踪。由程序产生每个函数调用和局部变量，传递的参数，调用位置等信息一起存储在堆栈内的数据块种，被称为一帧。我们可以使用GDB来检查所有这些数据。 GDB从最底层的帧开始给这些帧编号。
|
||||
|
||||
- **bt**: 打印整个堆栈的回溯
|
||||
- **bt <n>** 打印n个帧的回溯
|
||||
- **frame <frame number>**: 切换到指定的帧，并打印该帧
|
||||
- **up <n>**: 上移'n'个帧
|
||||
- **down <n>**: 下移'n'个帧 ( n默认是1)
|
||||
|
||||
#### 检查数据: ####
|
||||
|
||||
程序的数据可以在里面GDB使用'print'命令进行检查。例如，如果'X'是调试程序内的变量，'print x'会打印x的值。
|
||||
|
||||
#### 检查源码: ####
|
||||
|
||||
源码可以在GDB中打印。默认情况下，'list'命令会打印10行代码。
|
||||
|
||||
- **list <linenum>**: 列出'linenum'行周外的源码
|
||||
- **list <function>**: 从'function'开始列出源码
|
||||
- **disas <function>**: 显示该函数机器代码
|
||||
|
||||
#### 停止和恢复程序: ####
|
||||
|
||||
使用GDB，我们可以在必要的地方设置断点，观察点等来停止程序。
|
||||
|
||||
- **break <location>**: 在'location'设置一个断点。当在程序执行到这里时断点将被击中，控制权被交给用户。
|
||||
- **watch <expr>**: 当'expr'被程序写而且它的值发生变化时GDB将停止
|
||||
- **catch <event>**: 当'event'发生时GDB停止。
|
||||
- **disable <breakpoint>**: 禁用指定断点
|
||||
- **enable <breakpoint>**: 启用指定断点
|
||||
- **delete <breakpoint>**: 删除 断点/观察点/捕获点。 如果没有传递参数默认操作是在所有的断点。
|
||||
- **step**: 一步一步执行程序
|
||||
- **continue**: 继续执行程序，直到执行完毕
|
||||
|
||||
#### 退出 GDB: ####
|
||||
|
||||
用'quit'命令还从GDB中退出。
|
||||
|
||||
GDB还有更多的可用选项。里面GDB使用help选项了解更多详情。
|
||||
|
||||
|
||||
在GDB种获得帮助
|
||||
|
||||
### 总结 ###
|
||||
|
||||
在这篇文章中，我们已经看到不同类型的Linux用户空间的调试工具。总结以上所有内容，这是些什么时候使用该什么的快速指南：
|
||||
|
||||
基本调试，获得关键变量 - print 语句
|
||||
|
||||
获取有关文件系统支持，可用内存，CPU，运行程序的内核状态等信息 - 查询 /proc 文件系统
|
||||
|
||||
最初的问题诊断，系统调用或库调用的相关问题，了解程序流程 – strace / ltrace
|
||||
|
||||
应用程序内存空间的问题 – valgrind
|
||||
|
||||
检查应用程序运行时的行为，分析应用程序崩溃 – gdb。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-how-to/user-space-debugging-tools-linux/
|
||||
|
||||
作者：[B N Poornima][a]
|
||||
译者：[mtunique](https://github.com/mtunique)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://linoxide.com/author/bnpoornima/
|
||||
[1]:http://valgrind.org/downloads.html
|
||||
[2]:http://www.gnu.org/software/gdb/download/
|
||||
Loading…
Reference in New Issue
Block a user