简介： 本文主要对 UNIX 平台常见的问题进行了分类，介绍一些常见问题分析时使用的方法和命令，对以下三种常见问题的分析方法做了简单介绍：UNIX 下 Crash 问题的分析方法、UNIX 下内存泄露问题的分析方法和 UNIX 下 performance 问题的分析方法。

同时通过对下面两个例子的介绍，巩固了上面问题分析的介绍：

● 一个多线程应用的性能问题的分析

● 一个 crash 问题的分析

UNIX 程序常见问题分类

UNIX 下运行程序，经常会遇到以下几类问题 :

1. Crash

2. 内存泄露

3. 句柄泄露

4. 进程不响应

5. 性能不满足预期

6. 逻辑错误

UNIX 程序常见问题的分析方法

UNIX 下 Crash 问题的分析方法

crash 原理和 core 文件生成原因 ( 信号的介绍 )

Crash 是进程崩溃，是由于应用进程做了错误的操作 ( 例如，数组拷贝越界导致对系统内存进行了写操作，使用了错误的指针地址 ), 操作系统向应用进程发送了信号，如果应用进程没有做特殊处理，应用进程将 core dump 在进程当前的工作目录下生成一个 core 文件，core 文件复制了该进程的存储图像，是一个内存映像。

不是所有的信号默认行为都是 crash, 常见默认 crash 信号主要有：

可以通过 kill –l （适用所有 UNIX 平台）查看信号的信息。

查看针对某个进程的所有信号的默认行为（例如：在 Solaris 平台使用 psig pid 命令查看，其他平台的命令略有不同，请参考各自平台用户手册）.

下面列举一些常见信号的默认操作以及可能产生的原因：

例如：Solaris 平台如下。下面的信息参考 Solaris 内核结构第 2 版第二章（Solaris 进程模型） 第 75 页，其他平台基本相同，请参考各自平台用户手册：

信号 值 处理动作 发出信号的原因

SIGHUP 缺省的动作是终止进程 终端挂起或者控制进程终止

SIGINT 缺省的动作是终止进程 键盘中断（如 break 键被按下）

SIGQUIT 缺省的动作是终止进程并进行内核映像转储（dump core）键盘的退出键被按下

SIGILL 缺省的动作是终止进程并进行内核映像转储（dump core）非法指令

SIGABRT 缺省的动作是终止进程并进行内核映像转储（dump core）由 abort(3) 发出的退出指令

SIGFPE 缺省的动作是终止进程并进行内核映像转储（dump core）浮点异常

SIGKILL 9 AEF Kill 信号 终止信号

SIGSEGV 缺省的动作是终止进程并进行内核映像转储（dump core）无效的内存引用

SIGPIPE 缺省的动作是终止进程 管道破裂 : 写一个没有读端口的管道

SIGALRM 缺省的动作是终止进程 由 alarm(2) 发出的信号

SIGTERM 缺省的动作是终止进程 终止信号

SIGUSR1 缺省的动作是终止进程 用户自定义信号 1

SIGUSR2 缺省的动作是终止进程 用户自定义信号 2

SIGCHLD 缺省的动作是忽略此信号 子进程结束信号

SIGSTOP DEF 终止进程

SIGBUS 缺省的动作是终止进程并进行内核映像转储（dump core）总线错误 ( 错误的内存访问 )

core 文件分析一般思路

首先使用 file 命令（所有 UNIX 平台适用）查看 core 文件生成的源程序

从以上结果可以看出，该 core 文件是由 64 位程序 qatest 生成的。

然后使用 gdb( 或者 dbx) 对 core 文件进行分析：

再使用 where 命令查看 core 的位置：

从这个 core 文件可以看到，它收到了 BUS 信号，crash 的位置在 = s.GetValue()->Clone() 函数。

更多有关 gdb，dbx 的使用请参考 gdb，dbx 用户手册。

core 文件无法生成常见原因

当程序崩溃时，并不是总会生成 core 文件。经常有下面的情况导致 core 文件没有产生：

1. 对 core 文件大小做了限制，可以通过 ulimit（所有 UNIX 平台适用）的命令进行查看：

建议使用下面的命令将这个限制改为 unlimited

2. 磁盘空间是否充足，通过 df 命令（所有 UNIX 平台适用）查看 Available 的空间是否充足。

3. 查看信号是否被捕获（例如：Solaris 平台使用 psig 进行查看，见上面的例子，其他平台的命令略有不同，请参考各自平台用户手册）。

如果上面的情况导致 core 文件没有生成，请修改它。

4.没有 core 文件产生，如何分析 crash

有时候经常发现进程 crash 了，但是 core dump 文件没有产生。这时可以使用 dbx，gdb 等调试工具首先 attach 到运行的进程上，然后再执行业务，如果进程 crash，dbx 或者 gdb 将终止在 crash 的位置，我们便可以根据这个堆栈信息对 crash 进行分析，与分析 core 文件相同。

UNIX 下内存泄露问题分析方法

内存泄露简单的说就是申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。

封装 new 和 delete 对内存泄漏进行分析

通过对 new 和 delete 的封装，将 new 和 delete 的过程通过日志文件的保存记录下来。然后对日志文件进行分析，是否 new 和 delete 是匹配的，有哪些内存申请，但是没有释放。

下面通过一个简单的测试程序（此代码使用 C++ 语言实现，目前没有考虑申请数组的情况）进行演示：

这个测试程序申请了 pTemp1，pTemp2，pTemp3 的三块内存，但是仅仅释放了 pTemp3，存在 pTemp1 和 pTemp2 的内存泄露。

程序解释：

在每次内存申请时，将内存申请的信息注册到 MAP 表中，在每次内存释放时，将对应的内存信息从注册表中删除，这样注册表中将保存未释放的内存信息，按照一定的规则将注册表中的信息输出（定时或者进程退出等）。然后我们从输出信息中便可以分析出内存泄漏点。

通过自定义宏 DEMONEW 和 DEMODELETE 申请内存和释放内存，在这两个宏中，我们将内存的申请和释放做了记录，从而可以得到未释放内存的信息，请参考下面的程序实现流程图：

图 1. 内存申请释放流程：

图 2.DEMONEW 实现流程：

图 3.DEMODELETE 实现流程：

测试程序代码：

上面测试程序的输出是：

输出分析：

从输出结果我们可以发现，此测试程序在 test.cpp 文件的 109 和 111 行各有一处内存泄漏，查看源代码，它们分别是 pTemp1 和 pTemp2。

使用 Purify（适用所有 UNIX 平台）或者 valgrind（适用 Linux 平台）工具对内存泄漏进行分析

1. 使用 Purify 对内存泄漏进行分析

Purify 是 IBM Rational PurifyPlus 的工具之一， 是一个面向 VC、VB 或者 Java 开发的测试 Visual C/C++ 和 Java 代码中与内存有关的错误的工具，它确保整个应用程序的质量和可靠性。在查找典型的 C/C++ 程序中的传统内存访问错误， Rational Purify 可以大显身手。在 UNIX 系统中，使用 Purify 需要重新编译程序。通常的做法是修改 Makefile 中的编译器变量。

例如定义 CC 变量为 purify gcc

首先运行 Purify 安装目录下的 purifyplus_setup.sh 来设置环境变量，然后运行 make 重新编译程序。需要指出的是，程序必须编译成调试版本。在编译器命令（例如 Solaris 的 CC 编译器，Linux 的 gcc 编译器等）后，也就是必须使用”-g”选项。在重新编译的程序运行结束后，Purify 会打印出一个分析报告。

测试程序（此代码使用 C++ 语言实现）：

编译程序：

Purify 输出：

Purify 图形输出：

安装 Xmanager 等工具，设置 DISPLAY 为本机 IP，见下图

输出分析：

从 purify 的输出可以看出，此测试程序存在两处内存泄漏，它分别是 func2 和 func3，在 tst.cpp 文件的第 9 和第 14 行。

2. 使用 valgrind（现在仅仅支持 Linux 平台）对内存泄漏进行分析

Valgrind 是一套 Linux 下，开放源代码（GPL V2）的仿真调试工具的集合。Valgrind 由内核（core）以及基于内核的其他调试工具组成。内核类似于一个框架，它模拟了一个 CPU 环境，并提供服务给其他工具；而其他工具则类似于插件 (plug-in)，利用内核提供的服务完成各种特定的内存调试任务。Valgrind 在对程序进行侦测的时候，不需要对程序进行重新编译。

下面使用 valgrind 对一个简单的测试程序进行。

测试程序：

同 Purify 的测试程序相同。

编译程序：

valgrind 输出：

输出分析：

从 valgrind 的输出可以看出，此测试程序存在两处内存泄漏，它分别是 func2 和 func3，在 tst.cpp 文件的第 9 和第 14 行，与 purify 的检测结果相同。

UNIX 下进程性能问题分析方法

● 检查 CPU 占用情况（包含单个线程的 CPU 使用情况）

下面分别对 Solaris 和 Linux 平台做了举例，其他平台的命令略有不同，请参考各自平台用户手册。

例如：在 Solaris 平台

使用 prtdiag 命令查看系统 CPU 信息：

输出信息：

输出分析:

从上面的输出可以发现，此服务器有两个 CPU，以及各个 CPU 的信息。

使用 prstat 命令进程中每个线程的 CPU 使用情况：

输出信息：

输出分析：

LWPID 虽然不是线程 ID，但是在 Solaris10 版本与线程 ID 是一一对应关系，所以可以通过 LWPID 进行分析。

例如：在 Linux 平台

查看 CPU 个数 ( 使用 top 命令，然后按 1 键可显示 CPU 的个数以及每个 CPU 的负载情况 )：

输出信息：

输出分析：

从上面输出可以得到，此服务器有两个 CPU，均为满负荷工作，空闲的 CPU 使用均为 0%。

查看进程中每个线程的 CPU 使用情况：

–sort=%cpu 命令输出要求按 CPU 的使用多少进行排序输出。

输出信息：

输出分析：

从上面输出可以根据每个线程的 CPU 使用情况分析，性能瓶颈在哪个线程。

检查 IO

使用 iostat 命令可以查看系统 IO 状态等信息。

例如：Solaris 平台 iostat 输出：

上面是 iostat 的一个简单输出，可以查看 iostat 的帮助（man iostat）了解更多信息。

使用 Quantify 对程序性能进行分析

Rational Quantify 是 IBM Rational PurifyPlus 的工具之一，可以按多种级别（包括代码行级和函数级）测定性能，并提供分析性能改进所需的准确和详细的信息，使您可以核实代码性能确实有所提高。使用 Rational Quantify，您可以更好地控制数据记录的速度和准确性。您可以按模块调整工具收集信息的级别： 对于应用程序中感兴趣的那部分，可以收集详细信息；而对于不太重要的模块，您可以加快数据记录的速度并简化数据收集。使用“运行控制工具栏”，可以直接、 实时地控制性能数据的记录。既可以收集应用程序在整个运行过程中的性能数据，也可以只收集程序执行过程中您最感兴趣的某些阶段的性能数据。

下面是一个使用 Quantify 对程序性能进行分析的例子

测试程序（此代码使用 C++ 语言实现）

编译程序：

Quantify 输出：

Quantify 的图形输出：

安装 Xmanager 等工具，设置 DISPLAY 为本机 IP，见下图：

输出分析：

从 Quantify 的输出可以对程序的性能进行初步分析，func1 时间花费为 43.14%，func2 为 42.59%，func3 为 14.27%。

示例演示

通过两个实例去演示多线程性能问题和产品不兼容导致 crash 的问题。

一个多线程互斥导致性能瓶颈问题

1.问题描述：

对某个多线程程序，当单线程的情况下，执行任务 1 花费 70s，但是当配置为 16 个线程时，执行任务 1 仍然花费时间大约 70s。

2.问题分析：

首先查看单个线程或多个线程的 CPU 使用情况

从上面可以发现。当多线程的情况下，在 16 个线程中仅仅一个线程的 CPU 占用 6.25%，其他线程占用均为 0%。可以断定大多数的线程被 block 住。然后需要查看这个进程的堆栈信息，得到每个线程的函数调用关系。

从上面的线程堆栈信息，我们可以看到，大部分的线程几乎都 block 在 dynamic_cast 函数。

3.（3）问题解决：

针对上面的分析对这个性能瓶颈代码进行修正。

一个由于产品不兼容导致 crash 的问题

1. 问题描述：

在 Linux 平台，产品 A 使用编译器 icpc 编译，产品 B 使用编译器 g++ 编译。进程 C 会同时加载产品 A 与产品 B，当进程 C 运行时调用产品 A 中的函数 funcA 时 crash 发生。

2.问题分析：

从 core 文件，我们可以得到下面的信息：

查找产品 A 的依赖库，我们可以得到下面的信息

查找产品 B 的依赖库，我们可以得到下面的信息

这个 crash 的位置是在 stl 的 map 数据结构中，从上面的线程栈调用可以发现，4.1.2 为 libstdc++.so.6，但是从 A 的依赖库看，产品 A 依赖 libstdc++.so.5 而不是 libstdc++.so.6，所以 funcA 应该调用 libstdc++.so.5。

从上面我们可以发现 crash 的原因是由于 libstdc++.so 的调用错误导致的。

3.问题解决：

在编译选项中增加 -fvisibility=hidden ，在 API 声明中增加

UNIX 程序问题分析常用命令

1. ulimit — 设置和查看用户的使用的资源限制情况

2. nm — 显示目标文件的符号表信息

3. ldd –显示动态库的依赖信息

4. pstack（Solaris， Linux）， procstack（AIX）– 打印十六进制地址和符号名称

5. pmap(Solaris, Linux), procmap(AIX) –打印地址空间映射

6. pldd(Solaris), procldd(AIX) —列出进程加载的库

7. pfiles(Solaris), procfiles(AIX)– 报告有关的所有文件描述符

8. prstat(Solaris), ps -e -o user,pid,ppid,tid,time,%cpu,cmd –sort=%cpu(Linux)– 检查每个线程的处理器

9. ps –报告进程的状态

10. iostat –报告中央处理单元（中央处理器）统计和输入 / 输出设备和分区统计

11. pwdx（Linux，Solaris）  pid 显示当前工作目录

总结

本文简单介绍了作者在 UNIX 平台的一些经常遇到的问题以及一些基本命令的使用，希望对读者能有帮助。良好的基础知识（C/C++ 语言，操作系统，内核结构等）是分析问题解决问题的基础，同时一些 debug 工具以及一些第三方工具的熟练使用对问题分析也能很好的帮助作用。另外良好的编程习惯（例如申请的变量要初始化等）是避免问题产生的有效手段，在软件开发 前期的缺陷控制应该是我们的目标。