我们开启了 Shell 脚本调试系列文章，先是解释了不同的调试选项，下面介绍如何启用 Shell 调试模式。

写完脚本后，建议在运行脚本之前先检查脚本中的语法，而不是查看它们的输出以确认它们是否正常工作。

在本系列的这一部分，我们将了解如何使用语法检查调试模式。记住我们之前在本系列的第一部分中解释了不同的调试选项，在这里，我们将使用它们来执行脚本调试。

启用 verbose 调试模式

在进入本指导的重点之前，让我们简要地探索下 verbose 模式。它可以用 -v 调试选项来启用，它会告诉 shell 在读取时显示每行。

要展示这个如何工作，下面是一个示例脚本来批量将 PNG 图片转换成 JPG 格式。

将下面内容输入（或者复制粘贴）到一个文件中。

#!/bin/bash
#convert
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
done
exit 0

接着保存文件，并用下面的命令使脚本可执行：

$ chmod +x script.sh

我们可以执行脚本并显示它被 Shell 读取到的每一行：

$ bash -v script.sh

显示shell脚本中的所有行

在 Shell 脚本中启用语法检查调试模式

回到我们主题的重点，-n 激活语法检查模式。它会让 shell 读取所有的命令，但是不会执行它们，它（shell）只会检查语法。

一旦 shell 脚本中发现有错误，shell 会在终端中输出错误，不然就不会显示任何东西。

激活语法检查的命令如下：

$ bash -n script.sh

因为脚本中的语法是正确的，上面的命令不会显示任何东西。所以，让我们尝试删除结束 for 循环的 done 来看下是否会显示错误：

下面是修改过的含有 bug 的批量将 png 图片转换成 jpg 格式的脚本。

#!/bin/bash
#script with a bug
#convert
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
exit 0

保存文件，接着运行该脚本并执行语法检查：

$ bash -n script.sh

检查 shell 脚本语法

从上面的输出中，我们看到我们的脚本中有一个错误，for 循环缺少了一个结束的 done 关键字。shell 脚本从头到尾检查文件，一旦没有找到它（done），shell 会打印出一个语法错误：

script.sh: line 11: syntax error: unexpected end of file

我们可以同时结合 verbose 模式和语法检查模式：

$ bash -vn script.sh

在脚本中同时启用 verbose 检查和语法检查

另外，我们可以通过修改脚本的首行来启用脚本检查，如下面的例子：

#!/bin/bash -n
#altering the first line of a script to enable syntax checking
#convert
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
exit 0

如上所示，保存文件并在运行中检查语法：

$ ./script.sh
script.sh: line 12: syntax error: unexpected end of file

此外，我们可以用内置的 set 命令来在脚本中启用调试模式。

下面的例子中，我们只检查脚本中的 for 循环语法。

#!/bin/bash
#using set shell built-in command to enable debugging
#convert
#enable debugging
set -n
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
#disable debugging
set +n
exit 0

再一次保存并执行脚本：

$ ./script.sh 

总的来说，我们应该保证在执行 Shell 脚本之前先检查脚本语法以捕捉错误。

请在下面的反馈栏中，给我们发送关于这篇指导的任何问题或反馈。在这个系列的第三部分中，我们会解释并使用 shell 追踪调试模式。

作者简介：

Aaron Kili 是一个 Linux 及 F.O.S.S 热衷者，即将是 Linux 系统管理员、web 开发者，目前是 TecMint 的内容创作者，他喜欢用电脑工作，并热心分享知识。

via: http://www.tecmint.com/check-syntax-in-shell-script/

作者：Aaron Kili 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

gcc 编译器提供了几乎数不清的命令行选项列表。当然，没有人会使用过或者精通它所有的命令行选项，但是有一些命令行选项是每一个 gcc 用户都应该知道的 - 即使不是必须知道。它们中有一些很常用，其他一些不太常用，但不常用并不意味着它们的用处没前者大。

在这个系列的文章中，我们集中于一些不常用但是很有用的 gcc 命令行选项，在第一节已经讲到几个这样的命令行选项。

不知道你是否能够回想起，在这个系列教程的第一部分的开始，我简要的提到了开发者们通常用来生成警告的 -Wall 选项，并不包括一些特殊的警告。如果你不了解这些特殊警告，并且不知道如何生成它们，不用担心，我将在这篇文章中详细讲解关于它们所有的细节。

除此以外，这篇文章也将涉及与浮点值相关的 gcc 警告选项，以及在 gcc 命令行选项列表变得很大的时候如何更好的管理它们。

在继续之前，请记住，这个教程中的所有例子、命令和指令都已在 Ubuntu 16.04 LTS 操作系统和 gcc 5.4.0 上测试过。

生成 -Wall 选项不包括的警告

尽管 gcc 编译器的 -Wall 选项涵盖了绝大多数警告标记，依然有一些警告不能生成。为了生成它们，请使用 -Wextra 选项。

比如，下面的代码：

#include <stdio.h>
#include <stdlib.h>
int main()
{
    int i=0;
    /* ...
       some code here 
       ...
    */

    if(i);
        return 1;
     return 0; 
}

我不小心在 if 条件后面多打了一个分号。现在，如果使用下面的 gcc 命令来进行编译，不会生成任何警告。

gcc -Wall test.c -o test

但是如果同时使用 -Wextra 选项来进行编译：

gcc -Wall -Wextra test.c -o test

会生成下面这样一个警告：

test.c: In function ‘main’:
test.c:10:8: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
 if(i);

从上面的警告清楚的看到， -Wextra 选项从内部启用了 -Wempty-body 选项，从而可以检测可疑代码并生成警告。下面是这个选项启用的全部警告标记。

• -Wclobbered
• -Wempty-body
• -Wignored-qualifiers
• -Wmissing-field-initializers
• -Wmissing-parameter-type （仅针对 C 语言）
• -Wold-style-declaration （仅针对 C 语言）
• -Woverride-init
• -Wsign-compare
• -Wtype-limits
• -Wuninitialized
• -Wunused-parameter （只有和 -Wunused 或 -Wall 选项使用时才会启用）
• -Wunused-but-set-parameter (只有和-Wunused或-Wall` 选项使用时才会生成）

如果想对上面所提到的标记有更进一步的了解，请查看 gcc 手册。

此外，遇到下面这些情况， -Wextra 选项也会生成警告：

• 一个指针和整数 0 进行 <， <=， >， 或 >= 比较
• （仅 C++）一个枚举类型和一个非枚举类型同时出现在一个条件表达式中
• （仅 C++）有歧义的虚拟基底
• （仅 C++）寄存器类型的数组加下标
• （仅 C++）对寄存器类型的变量进行取址
• （仅 C++）基类没有在派生类的复制构建函数中进行初始化

浮点值的等值比较时生成警告

你可能已经知道，浮点值不能进行确切的相等比较（如果不知道，请阅读与浮点值比较相关的 FAQ)。但是如果你不小心这样做了， gcc 编译器是否会报出错误或警告？让我们来测试一下：

下面是一段使用 == 运算符进行浮点值比较的代码：

#include<stdio.h>

void compare(float x, float y)
{
    if(x == y)
    {
        printf("\n EQUAL \n");
    }
}

int main(void)
{
    compare(1.234, 1.56789);

    return 0; 
}

使用下面的 gcc 命令（包含 -Wall 和 -Wextra 选项）来编译这段代码：

gcc -Wall -Wextra test.c -o test

遗憾的是，上面的命令没有生成任何与浮点值比较相关的警告。快速看一下 gcc 手册，在这种情形下可以使用一个专用的 -Wfloat-equal 选项。

下面是包含这个选项的命令：

gcc -Wall -Wextra -Wfloat-equal test.c -o test

下面是这条命令产生的输出：

test.c: In function ‘compare’:
test.c:5:10: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
 if(x == y)

正如上面你所看到的输出那样， -Wfloat-equal 选项会强制 gcc 编译器生成一个与浮点值比较相关的警告。

这儿是gcc 手册关于这一选项的说明：

这背后的想法是，有时，对程序员来说，把浮点值考虑成近似无限精确的实数是方便的。如果你这样做，那么你需要通过分析代码，或者其他方式，算出这种计算方式引入的最大或可能的最大误差，然后进行比较时（以及产生输出时，不过这是一个不同的问题）允许这个误差。特别要指出，不应该检查是否相等，而应该检查两个值是否可能出现范围重叠；这是用关系运算符来做的，所以等值比较可能是搞错了。

如何更好的管理 gcc 命令行选项

如果在你使用的 gcc 命令中，命令行选项列表变得很大而且很难管理，那么你可以把它放在一个文本文件中，然后把文件名作为 gcc 命令的一个参数。之后，你必须使用 @file 命令行选项。

比如，下面这行是你的 gcc 命令：

gcc -Wall -Wextra -Wfloat-equal test.c -o test

然后你可以把这三个和警告相关的选项放到一个文件里，文件名叫做 gcc-options：

$ cat gcc-options 
-Wall -Wextra -Wfloat-equal

这样，你的 gcc 命令会变得更加简洁并且易于管理：

gcc @gcc-options test.c -o test

下面是 gcc 手册关于 @file 的说明：

从文件中读取命令行选项。读取到的选项随之被插入到原始 @file 选项所在的位置。如果文件不存在或者无法读取，那么这个选项就会被当成文字处理，而不会被删除。

文件中的选项以空格分隔。选项中包含空白字符的话，可以用一个由单引号或双引号包围完整选项。任何字符（包括反斜杠: '\'）均可能通过一个 '\' 前缀而包含在一个选项中。如果该文件本身包含额外的 @file 选项，那么它将会被递归处理。

结论

在这个系列的教程中，我们一共讲解了 5 个不常见但是很有用的 gcc 命令行选项： -Save-temps、-g、 -Wextra、-Wfloat-equal 以及 @file。记得花时间练习使用每一个选项，同时不要忘了浏览 gcc 手册上面所提供的关于它们的全部细节。

你是否知道或使用其他像这样有用的 gcc 命令行选项，并希望把它们在全世界范围内分享？请在下面的评论区留下所有的细节。

via: https://www.howtoforge.com/tutorial/uncommon-but-useful-gcc-command-line-options-2/

作者：Ansh 译者：ucasFL 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

脚本是存储在一个文件的一系列命令。在终端上输入一个个命令，按顺序执行的方法太弱了，使用脚本，系统中的用户可以在一个文件中存储所有命令，反复调用该文件多次重新执行命令。

在学习脚本或写脚本的初期阶段，我们通常从写小脚本或者几行命令的短脚本开始，调试这样的脚本时我们通常无非就是通过观察它们的输出来确保其正常工作。

然而，当我们开始写非常长或上千行命令的高级脚本，例如改变系统设置的脚本，在网络上执行关键备份 等等，我们会意识到仅仅看脚本输出是不足以在脚本中找到 Bug 的！

因此，在 Linux 系列中这篇介绍 Shell 脚本调试， 我们将看看如何启用 Shell 脚本调试，然后在之后的系列中解释不同的 Shell 脚本调试模式以及如何使用它们。

如何开始写一个脚本

一个脚本与其它文件的区别是它的首行，它包含 #! （She-Bang - 释伴：定义文件类型）和路径名（解释器路径），通知系统该文件是一个命令集合，将被指定程序(解释器)解释。

下面是不同类型脚本 首行 示例：

#!/bin/sh          [sh 脚本]
#!/bin/bash        [bash 脚本] 
#!/usr/bin/perl    [perl 程序]
#!/bin/awk -f      [awk 脚本]   

注意：如果脚本仅包含一组标准系统命令，没有任何内部 Shell 指令，首行或 #! 可以去掉。

如何在 Linux 操作系统执行 Shell 脚本

调用一个脚本脚本的常规语法是：

$ 脚本名  参数1 ... 参数N

另一种可能的形式是明确指定将执行这个脚本的 Shell，如下：

$ shell 脚本名  参数1 ... 参数N

示例：

$ /bin/bash   参数1 ... 参数N     [bash 脚本]
$ /bin/ksh   参数1 ... 参数N      [ksh 脚本]
$ /bin/sh   参数1 ... 参数N       [sh 脚本]

对于没有 #! 作为首行，仅包含基础系统命令的脚本，示例如下：

### 脚本仅包含标准系统命令
cd /home/$USER
mkdir tmp
echo "tmp directory created under /home/$USER"

使它可执行并运行，如下：

$ chmod +x  脚本名
$ ./脚本名 

启用 Shell 脚本调试模式的方法

下面是主要的 Shell 脚本调试选项：

• -v （verbose 的简称） - 告诉 Shell 读取脚本时显示所有行，激活详细模式。
• -n （noexec 或 no ecxecution 简称） - 指示 Shell 读取所有命令然而不执行它们，这个选项激活语法检查模式。
• -x （xtrace 或 execution trace 简称） - 告诉 Shell 在终端显示所有执行的命令和它们的参数。 这个选项是启用 Shell 跟踪模式。

1、 改变 Shell 脚本首行

第一个机制是改变 Shell 脚本首行，如下，这会启动脚本调试。

#!/bin/sh 选项

其中， 选项可以是上面提到的一个或多个调试选项。

2、 调用 Shell 调试选项

第二个是使用如下调试选项启动 Shell，这个方法也会打开整个脚本调试。

$ shell 选项   参数1 ... 参数N

示例：

$ /bin/bash 选项   参数1 ... 参数N

3、 使用 Shell 内置命令 set

第三个方法是使用内置命令 set 去调试一个给定的 Shell 脚本部分，如一个函数。这个机制是重要的，因为它让我们可以去调试任何一段 Shell 脚本。

我们可以如下使用 set 命令打开调试模式，其中选项是之前提到的所有调试选项。

$ set 选项 

启用调试模式：

$ set -选项

禁用调试模式：

$ set +选项

此外，如果我们在 Shell 脚本不同部分启用了几个调试模式，我们可以一次禁用所有调试模式，如下：

$ set -

关于启用 Shell 脚本调试模式，先讲这些。正如我们看到的，我们可以调试一整个 Shell 脚本或者特定部分脚本。

在此系列下面的两篇文章中，我们会举例介绍如何使用 Shell 脚本调试选项，进一步了解 详细 （ verbose ） 、 语法检查 （ syntax checking ） 、 跟踪 （ tracing ） 调试模式。

更重要的是，关于这个指南，欢迎通过下面评论提出任何问题或反馈。

via: http://www.tecmint.com/enable-shell-debug-mode-linux/

作者：Aaron Kili 译者：imxieke 校对：jasminepeng

本文由 LCTT 组织编译，Linux中国 荣誉推出

软件工具通常情况下会提供多个功能以供选择，但是如你所知的，不是所有的功能都能被每个人用到的。公正地讲，这并不是设计上的错误，因为每个用户都会有自己的需求，他们只在他们的领域内使用该工具。然而，深入了解你所使用的工具也是很有益处的，因为你永远不知道它的某个功能会在什么时候派上用场，从而节省下你宝贵的时间。

举一个例子：编译器。一个优秀的编程语言编译器总是会提供极多的选项，但是用户一般只知道和使用其中很有限的一部分功能。更具体点来说，比如你是 C 语言开发人员，并将 Linux 作为你的开发平台，那么你很有可能会用到 gcc 编译器，这个编译器提供了 (几乎) 数不清的命令行选项列表。

你知道，你可以让 gcc 保存每个编译阶段的输出吗？你知道用于生成警告的 -Wall 选项，它并不会包含一些特殊的警告吗？gcc 的很多命令行选项都不会经常用到，但是它们在某些特定的情况下会变得非常有用，例如，当你在调试代码的时候。

所以在本文中，我们会介绍这样的几个选项，提供所有必要的细节，并通过简单易懂的例子来解释它们。

但是在开始前，请注意本文中所有的例子所使用的环境：基于 Ubuntu 16.04 LTS 操作系统，gcc 版本为 5.4.0。

在每个编译阶段查看中间代码的输出

你知道在通过 gcc 编译 c 语言代码的时候大体上共分为四个阶段吗？分别为预处理 -> 编译 -> 汇编 -> 链接。在每个阶段之后，gcc 都会产生一个将移交给下一个阶段的临时输出文件。但是生成的都是临时文件，因此我们并不能看到它们——我们所看到的只是我们发起编译命令，然后它生成的我们可以直接运行的二进制文件或可执行文件。

但是比如说在预处理阶段，如果调试时需要查看代码是如何进行处理的，你要怎么做呢？好消息是 gcc 编译器提供了相应的命令行选项，你可以在标准编译命令中使用这些选项获得原本被编译器删除的中间文件。我们所说的选项就是-save-temps。

以下是 gcc 手册中对该选项的介绍：

永久存储临时的中间文件，将它们放在当前的文件夹下并根据源文件名称为其命名。因此，用 -c -save-temps 命令编译 foo.c 文件时会生成 foo.i foo.s 和 foo.o 文件。即使现在编译器大多使用的是集成的预处理器，这命令也会生成预处理输出文件 foo.i。

当与 -x 命令行选项结合使用时，-save-temps 命令会避免覆写与中间文件有着相同扩展名的输入源文件。相应的中间文件可以通过在使用 -save-temps 命令之前重命名源文件获得。

以下是怎样使用这个选项的例子：

gcc -Wall -save-temps test.c -o test-exec

下图为该命令的执行结果，验证其确实产生了中间文件：

因此，在截图中你所看到的 test.i、test.s、 test.o 文件都是由 -save-temps 选项产生的。这些文件分别对应于预处理、编译和链接阶段。

让你的代码可调试和可分析

你可以使用专有的工具调试和分析代码。如 gdb 就是专用于调试的工具，而 gprof 则是热门的分析工具。但你知道 gcc 特定的命令行选项也可以让你的代码可调试和可分析吗？

让我们开始调试之路吧！为了能在代码调试中使用 gdb，你需要在编译代码的时候使用 gcc 编译器提供的 -g 选项。这个选项让 gcc 生成 gdb 需要的调试信息从而能成功地调试程序。

如果你想要使用此选项，建议您详细阅读 gcc 手册提供的有关此选项的详细信息——在某些情况下，其中的一些内容可能是至关重要的。 例如，以下是从手册页中摘录的内容：

GCC 允许在使用 -g 选项的时候配合使用 -O 选项。优化代码采用的便捷方式有时可能会产生意想不到的结果：某些你声明的变量可能不复存在；控制流可能会突然跳转到你未曾预期的位置；一些语句也许不会执行，因为它们已经把常量结果计算了或值已经被保存；一些语句可能会在不同地方执行，因为它们已经被移出循环。

然而优化的输出也是可以调试的。这就使得让优化器可以合理地优化或许有 bug 的代码。

不只是 gdb，使用 -g 选项编译代码，还可以开启使用 Valgrind 内存检测工具，从而完全发挥出该选项的潜力。或许还有一些人不知道，mencheck 工具被程序员们用来检测代码中是否存在内存泄露。你可以在这里参见这个工具的用法。

继续往下，为了能够在代码分析中使用 gprof 工具，你需要使用 -pg 命令行选项来编译代码。这会让 gcc 生成额外的代码来写入分析信息，gprof 工具需要这些信息来进行代码分析。gcc 手册 中提到：当编译你需要数据的源文件时，你必须使用这个选项，当然链接时也需要使用它。为了能了解 gprof 分析代码时具体是如何工作的，你可以转到我们的网站专用教程进行了解。

注意：-g 和 -pg 选项的用法类似于上一节中使用 -save-temps 选项的方式。

结论

我相信除了 gcc 的专业人士，都可以在这篇文章中得到了一些启发。尝试一下这些选项，然后观察它们是如何工作的。同时，请期待本教程系列的下一部分，我们将会讨论更多有趣和有用的 gcc 命令行选项。

via: https://www.howtoforge.com/tutorial/uncommon-but-useful-gcc-command-line-options/

作者：Ansh 译者：dongdongmian 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Credit: Moini

作为一个程序员，我知道我肯定会犯错误——怎么可能不犯错！程序员也是人啊。有的错误能在编码过程中及时发现，而有些却得等到软件测试了才能显露出来。然而，还有一类错误并不能在这两个阶段被解决，这就导致软件不能正常运行，甚至是提前终止。

如果你还没猜出是那种错误，我说的就是和内存相关的错误。手动调试这些错误不仅耗时，而且很难发现并纠正。值得一提的是，这种错误很常见，特别是在用 C/C++ 这类允许手动管理内存的语言编写的软件里。

幸运的是，现在有一些编程工具能够帮你在软件程序中找到这些和内存相关的错误。在这些工具集中，我评估了五款支持 Linux 的、流行的、自由开源的内存调试器： Dmalloc 、 Electric Fence 、 Memcheck 、 Memwatch 以及 Mtrace 。在日常编码中，我已经用过这五个调试器了，所以这些评估是建立在我的实际体验之上的。

Dmalloc

开发者：Gray Watson

评估版本：5.5.2

支持的 Linux 版本：所有种类

许可： CC 3.0

Dmalloc 是 Gray Watson 开发的一款内存调试工具。它是作为库来实现的，封装了标准内存管理函数如malloc() , calloc() , free()等，使程序员得以检测出有问题的代码。

Dmalloc

如同工具的网页所示，这个调试器提供的特性包括内存泄漏跟踪、 重复释放内存 （ double free ） 错误跟踪、以及 越界写入 （ fence-post write ） 检测。其它特性包括报告错误的文件/行号、通用的数据统计记录。

更新内容

5.5.2 版本是一个 bug 修正发行版，修复了几个有关构建和安装的问题。

有何优点

Dmalloc 最大的优点就是高度可配置性。比如说，你可以配置它以支持 C++ 程序和多线程应用。 Dmalloc 还提供一个有用的功能：运行时可配置，这表示在 Dmalloc 执行时，可以轻易地启用或者禁用它提供的一些特性。

你还可以配合 GNU Project Debugger (GDB)来使用 Dmalloc ，只需要将dmalloc.gdb文件（位于 Dmalloc 源码包中的 contrib 子目录里）的内容添加到你的主目录中的.gdbinit文件里即可。

另外一个让我对 Dmalloc 爱不释手的优点是它有大量的资料文献。前往官网的 Documentation 栏目，可以获取所有关于如何下载、安装、运行、怎样使用库，和 Dmalloc 所提供特性的细节描述，及其生成的输出文件的解释。其中还有一个章节介绍了一般问题的解决方法。

注意事项

跟 Mtrace 一样， Dmalloc 需要程序员改动他们的源代码。比如说你可以（也是必须的）添加头文件dmalloc.h，工具就能汇报产生问题的调用的文件或行号。这个功能非常有用，因为它节省了调试的时间。

除此之外，还需要在编译你的程序时，把 Dmalloc 库（编译 Dmalloc 源码包时产生的）链接进去。

然而，还有点更麻烦的事，需要设置一个环境变量，命名为DMALLOC_OPTION，以供工具在运行时配置内存调试特性，比如定义输出文件的路径。可以手动为该环境变量分配一个值，不过初学者可能会觉得这个过程有点困难，因为该值的一部分用来表示要启用的 Dmalloc 特性——以十六进制值的累加值表示。这里有详细介绍。

一个比较简单方法设置这个环境变量是使用 Dmalloc 实用指令，这是专为这个目的设计的方法。

总结

Dmalloc 真正的优势在于它的可配置选项。而且高度可移植，曾经成功移植到多种操作系统如 AIX 、 BSD/OS 、 DG/UX 、 Free/Net/OpenBSD 、 GNU/Hurd 、 HPUX 、 Irix 、 Linux 、 MS-DOG 、 NeXT 、 OSF 、 SCO 、 Solaris 、 SunOS 、 Ultrix 、 Unixware 甚至 Unicos（运行在 Cray T3E 主机上）。虽然使用 Dmalloc 需要学习许多知识，但是它所提供的特性值得为之付出。

Electric Fence

开发者：Bruce Perens

评估版本：2.2.3

支持的 Linux 版本：所有种类

许可：GPL v2

Electric Fence 是 Bruce Perens 开发的一款内存调试工具，它以库的形式实现，你的程序需要链接它。Electric Fence 能检测出堆内存溢出和访问已经释放的内存。

Electric Fence

顾名思义， Electric Fence 在每个所申请的缓存边界建立了虚拟围栏，这样一来任何非法的内存访问都会导致段错误。这个调试工具同时支持 C 和 C++ 程序。

更新内容

2.2.3 版本修复了工具的构建系统，使得 -fno-builtin-malloc 选项能真正传给 GNU Compiler Collection (GCC)。

有何优点

我喜欢 Electric Fence 的首要一点是它不同于 Memwatch 、 Dmalloc 和 Mtrace ，不需要对你的源码做任何的改动，你只需要在编译的时候把它的库链接进你的程序即可。

其次， Electric Fence 的实现保证了产生越界访问的第一个指令就会引起段错误。这比在后面再发现问题要好多了。

不管是否有检测出错误， Electric Fence 都会在输出产生版权信息。这一点非常有用，由此可以确定你所运行的程序已经启用了 Electric Fence 。

注意事项

另一方面，我对 Electric Fence 真正念念不忘的是它检测内存泄漏的能力。内存泄漏是 C/C++ 软件最常见也是最不容易发现的问题之一。不过， Electric Fence 不能检测出栈溢出，而且也不是线程安全的。

由于 Electric Fence 会在用户分配内存区的前后分配禁止访问的虚拟内存页，如果你过多的进行动态内存分配，将会导致你的程序消耗大量的额外内存。

Electric Fence 还有一个局限是不能明确指出错误代码所在的行号。它所能做只是在检测到内存相关错误时产生段错误。想要定位错误的行号，需要借助 GDB这样的调试工具来调试启用了 Electric Fence 的程序。

最后一点，尽管 Electric Fence 能检测出大部分的缓冲区溢出，有一个例外是，如果所申请的缓冲区大小不是系统字长的倍数，这时候溢出（即使只有几个字节）就不能被检测出来。

总结

尽管局限性较大， Electric Fence 的易用性仍然是加分项。只要链接一次程序， Electric Fence 就可以在监测出内存相关问题的时候报警。不过，如同前面所说， Electric Fence 需要配合像 GDB 这样的源码调试器使用。

Memcheck

开发者：Valgrind 开发团队

评估版本：3.10.1

支持的 Linux 发行版：所有种类

许可：GPL

Valgrind 是一个提供好几款调试和分析 Linux 程序性能的工具的套件。虽然 Valgrind 能和不同语言——Java 、 Perl 、 Python 、 Assembly code 、 ortran 、 Ada 等——编写的程序一起工作，但是它主要还是针对使用 C/C++ 所编写的程序。

Memcheck ，一款内存错误检测器，是其中最受欢迎的工具。它能够检测出如内存泄漏、无效的内存访问、未定义变量的使用以及堆内存分配和释放相关的问题等诸多问题。

更新内容

工具套件( 3.10.1 )主要修复了 3.10.0 版本发现的 bug 。除此之外，“从主干开发版本向后移植的一些补丁，修复了缺失的 AArch64 ARMv8 指令和系统调用”。

有何优点

同其它所有 Valgrind 工具一样， Memcheck 也是命令行程序。它的操作非常简单：通常我们会使用诸如 prog arg1 arg2 格式的命令来运行程序，而 Memcheck 只要求你多加几个值即可，如 valgrind --leak-check=full prog arg1 arg2 。

Memcheck

（注意：因为 Memcheck 是 Valgrind 的默认工具，所以在命令行执行命令时无需提及 Memcheck。但是，需要在编译程序之初带上 -g 参数选项，这一步会添加调试信息，使得 Memcheck 的错误信息会包含正确的行号。）

我真正倾心于 Memcheck 的是它提供了很多命令行选项（如上所述的--leak-check选项），如此不仅能控制工具运转还可以控制它的输出。

举个例子，可以开启--track-origins选项，以查看程序源码中未初始化的数据；可以开启--show-mismatched-frees选项让 Memcheck 匹配内存的分配和释放技术。对于 C 语言所写的代码， Memcheck 会确保只能使用free()函数来释放内存，malloc()函数来申请内存。而对 C++ 所写的源码， Memcheck 会检查是否使用了delete或delete[]操作符来释放内存，以及new或者new[]来申请内存。

Memcheck 最好的特点，尤其是对于初学者来说，是它会给用户建议使用哪个命令行选项能让输出更加有意义。比如说，如果你不使用基本的--leak-check选项， Memcheck 会在输出时给出建议：“使用 --leak-check=full 重新运行以查看更多泄漏内存细节”。如果程序有未初始化的变量， Memcheck 会产生信息：“使用 --track-origins=yes 以查看未初始化变量的定位”。

Memcheck 另外一个有用的特性是它可以创建 抑制文件 （ suppression files ） ，由此可以略过特定的不能修正的错误，这样 Memcheck 运行时就不会每次都报警了。值得一提的是， Memcheck 会去读取默认抑制文件来忽略系统库（比如 C 库）中的报错，这些错误在系统创建之前就已经存在了。可以选择创建一个新的抑制文件，或是编辑现有的文件(通常是/usr/lib/valgrind/default.supp)。

Memcheck 还有高级功能，比如可以使用定制内存分配器来检测内存错误。除此之外， Memcheck 提供监控命令，当用到 Valgrind 内置的 gdbserver ，以及客户端请求机制（不仅能把程序的行为告知 Memcheck ，还可以进行查询）时可以使用。

注意事项

毫无疑问， Memcheck 可以节省很多调试时间以及省去很多麻烦。但是它使用了很多内存，导致程序执行变慢（由文档可知，大概会花费 20 至 30 倍时间）。

除此之外， Memcheck 还有其它局限。根据用户评论， Memcheck 很明显不是线程安全的；它不能检测出 静态缓冲区溢出；还有就是，一些 Linux 程序如 GNU Emacs 目前还不能配合 Memcheck 工作。

如果有兴趣，可以在这里查看 Valgrind 局限性的详细说明。

总结

无论是对于初学者还是那些需要高级特性的人来说， Memcheck 都是一款便捷的内存调试工具。如果你仅需要基本调试和错误检查， Memcheck 会非常容易上手。而当你想要使用像抑制文件或者监控指令这样的特性，就需要花一些功夫学习了。

虽然罗列了大量的局限性，但是 Valgrind（包括 Memcheck ）在它的网站上声称全球有成千上万程序员使用了此工具。开发团队称收到来自超过 30 个国家的用户反馈，而这些用户的工程代码有的高达两千五百万行。

Memwatch

开发者：Johan Lindh

评估版本：2.71

支持的 Linux 发行版：所有种类

许可：GNU GPL

Memwatch 是由 Johan Lindh 开发的内存调试工具，虽然它扮演的主要角色是内存泄漏检测器，但是（根据网页介绍）它也具有检测其它如内存重复释放和错误释放、缓冲区溢出和下溢、野指针写入等等内存相关问题的能力。

Memwatch 支持用 C 语言所编写的程序。也可以在 C++ 程序中使用它，但是这种做法并不提倡（由 Memwatch 源码包随附的 Q&A 文件中可知）。

更新内容

这个版本添加了ULONG_LONG_MAX以区分 32 位和 64 位程序。

有何优点

跟 Dmalloc 一样， Memwatch 也有优秀的文档资料。参考 USING 文件，可以学习如何使用 Memwatch ，可以了解 Memwatch 是如何初始化、如何清理以及如何进行 I/O 操作，等等。还有一个 FAQ 文件，旨在帮助用户解决使用过程遇到的一般问题。最后还有一个test.c文件提供工作案例参考。

Memwatch

不同于 Mtrace ， Memwatch 产生的日志文件（通常是memwatch.log）是人类可阅读的格式。而且， Memwatch 每次运行时总会把内存调试结果拼接到输出该文件的末尾。如此便可在需要之时轻松查看之前的输出信息。

同样值得一提的是当你执行了启用 Memwatch 的程序， Memwatch 会在标准输出中产生一个单行输出，告知发现了错误，然后你可以在日志文件中查看输出细节。如果没有产生错误信息，就可以确保日志文件不会写入任何错误，多次运行的话确实能节省时间。

另一个我喜欢的优点是 Memwatch 还提供了在源码中获取其输出信息的方式，你可以获取信息，然后任由你进行处理（参考 Memwatch 源码中的mwSetOutFunc()函数获取更多有关的信息）。

注意事项

跟 Mtrace 和 Dmalloc 一样， Memwatch 也需要你往你的源文件里增加代码：你需要把memwatch.h这个头文件包含进你的代码。而且，编译程序的时候，你需要连同memwatch.c一块编译；或者你可以把已经编译好的目标模块包含起来，然后在命令行定义MEMWATCH和MW_STDIO变量。不用说，想要在输出中定位行号， -g 编译器选项也少不了。

此外， Memwatch 缺少一些特性。比如 Memwatch 不能检测出对一块已经被释放的内存进行写入操作，或是在分配的内存块之外的进行读取操作。而且， Memwatch 也不是线程安全的。还有一点，正如我在开始时指出，在 C++ 程序上运行 Memwatch 的结果是不能预料的。

总结

Memcheck 可以检测很多内存相关的问题，在处理 C 程序时是非常便捷的调试工具。因为源码小巧，所以可以从中了解 Memcheck 如何运转，有需要的话可以调试它，甚至可以根据自身需求扩展升级它的功能。

Mtrace

开发者: Roland McGrath 和 Ulrich Drepper

评估版本: 2.21

支持的 Linux 发行版：所有种类

许可：GNU GPL

Mtrace 是 GNU C 库中的一款内存调试工具，同时支持 Linux 上的 C 和 C++ 程序，可以检测由函数malloc()和free()不匹配的调用所引起的内存泄漏问题。

Mtrace

Mtrace 实际上是实现了一个名为mtrace()的函数，它可以跟踪程序中所有 malloc/free 调用，并在用户指定的文件中记录相关信息。文件以一种机器可读的格式记录数据，所以有一个 Perl 脚本——同样命名为 mtrace ——用来把文件转换并为人类可读格式。

更新内容

Mtrace 源码和 Perl 文件同 GNU C 库( 2.21 版本)一起释出，除了更新版权日期，其它别无改动。

有何优点

Mtrace 最好的地方是它非常简单易学。你只需要了解在你的源码中如何以及何处添加 mtrace() 及对应的 muntrace() 函数，还有如何使用 Mtrace 的 Perl 脚本。后者非常简单，只需要运行指令mtrace <program-executable> <log-file-generated-upon-program-execution>（例子见开头截图最后一条指令）。

Mtrace 另外一个优点是它的可伸缩性，这体现在不仅可以使用它来调试完整的程序，还可以使用它来检测程序中独立模块的内存泄漏。只需在每个模块里调用mtrace()和muntrace()即可。

最后一点，因为 Mtrace 会在mtrace()——在源码中添加的函数——执行时被触发，因此可以很灵活地使用信号动态地（在程序执行时）使能 Mtrace 。

注意事项

因为mtrace()和mauntrace()函数 —— 声明在mcheck.h文件中，所以必须在源码中包含此头文件 —— 的调用是 Mtrace 工作的基础（mauntrace()函数并非总是必要），因此 Mtrace 要求程序员至少改动源码一次。

需要注意的是，在编译程序的时候带上 -g 选项（ GCC 和 G++ 编译器均有提供），才能使调试工具在输出结果时展示正确的行号。除此之外，有些程序（取决于源码体积有多大）可能会花很长时间进行编译。最后，带 -g 选项编译会增加了可执行文件的大小（因为提供了额外的调试信息），因此记得程序需要在测试结束后，不带 -g 选项重新进行编译。

使用 Mtrace ，你需要掌握 Linux 环境变量的基本知识，因为在程序执行之前，需要把用户把环境变量MALLOC_TRACE的值设为指定的文件（mtrace()函数将会记录全部信息到其中）路径。

Mtrace 在检测内存泄漏和试图释放未经过分配的内存方面存在局限。它不能检测其它内存相关问题如非法内存访问、使用未初始化内存。而且，有人抱怨 Mtrace 不是线程安全的。

总结

不言自明，我在此讨论的每款内存调试器都有其优点和局限。所以，哪一款适合你取决于你所需要的特性，虽然有时候容易安装和使用也是一个决定因素。

要想捕获软件程序中的内存泄漏， Mtrace 最适合不过了。它还可以节省时间。由于 Linux 系统已经预装了此工具，对于不能联网或者不可以下载第三方调试调试工具的情况， Mtrace 也是极有助益的。

另一方面，相比 Mtrace ， Dmalloc 不仅能检测更多错误类型，还提供更多特性，比如运行时可配置、 GDB 集成。而且， Dmalloc 不像这里所说的其它工具，它是线程安全的。更不用说它的详细资料了，这让 Dmalloc 成为初学者的理想选择。

虽然 Memwatch 的资料比 Dmalloc 的更加丰富，而且还能检测更多的错误种类，但是你只能在 C 语言写就的程序中使用它。一个让 Memwatch 脱颖而出的特性是它允许在你的程序源码中处理它的输出，这对于想要定制输出格式来说是非常有用的。

如果改动程序源码非你所愿，那么使用 Electric Fence 吧。不过，请记住， Electric Fence 只能检测两种错误类型，而此二者均非内存泄漏。还有就是，需要基本了解 GDB 以最大化发挥这款内存调试工具的作用。

Memcheck 可能是其中综合性最好的了。相比这里提及的其它工具，它能检测更多的错误类型，提供更多的特性，而且不需要你的源码做任何改动。但请注意，基本功能并不难上手，但是想要使用它的高级特性，就必须学习相关的专业知识了。

via: http://www.computerworld.com/article/3003957/linux/review-5-memory-debuggers-for-linux-coding.html

作者：Himanshu Arora 译者：soooogreen 校对：PurlingNayuki,ezio

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你读过我写的使用GDB命令行调试器调试C/C++程序，你就会明白一个调试器对一段C/C++程序来说有多么的重要和有用。然而，如果一个像GDB这样的命令行对你而言听起来更像一个问题而不是一个解决方案的话，那么你也许会对Nemiver更感兴趣。Nemiver 是一款基于 GTK+ 的用于C/C++程序的图形化的独立调试器，它以GDB作为其后端。最令人赞赏的是其速度和稳定性，Nemiver是一个非常可靠，具备许多优点的调试工具。

Nemiver的安装

基于Debian发行版，它的安装时非常直接简单，如下：

$ sudo apt-get install nemiver 

在Arch Linux中安装如下：

$ sudo pacman -S nemiver 

在Fedora中安装如下：

$ sudo yum install nemiver 

如果你选择自己编译，GNOME 网站上有最新源码包。

最令人欣慰的是，它能够很好地与GNOME环境像结合。

Nemiver的基本用法

启动Nemiver的命令：

$ nemiver 

你也可以通过执行一下命令来启动：

$ nemiver [需要调试的可执行程序的路径] 

注意，如果在调试模式下编译程序（在 GCC 中使用 -g 选项）将会对 nemiver 更有帮助。

还有一个优点是Nemiver的加载很快，所以你马上就可以看到主屏幕的默认布局。

默认情况下，断点通常位于主函数的第一行。这样就可以空出时间让你去认识调试器的基本功能：

• 执行到下一行 （按键是F6）
• 执行到函数内部即停止（F7）
• 执行到函数外部即停止（Shift+F7）

不过我个人喜欢“Run to cursor（运行至光标所在行）”，该选项使你的程序准确的运行至你光标所在行，它的默认按键是F11。

断点是很容易使用的。最快捷的方式是在一行代码上按下F8来设置一个断点。但是Nemiver在“Debug”菜单下也有一个更复杂的菜单，它允许你在一个特定的函数，某一行，二进制文件中的位置，或者类似异常、分支或者exec的事件上设置断点。

你也可以通过追踪来查看一个变量。在“Debug”中，你可以用一个表达式的名字来检查它的值，然后也可以通过将其添加到列表中以方便访问。这可能是最有用的一个功能，虽然我从未有兴趣将鼠标悬停在一个变量来获取它的值。值得注意的是，虽然鼠标悬停可以取到值，如果想要让它更好地工作，Nemiver是可以看到结构并给出所有成员的变量的赋值。

谈到方便地访问信息，我也非常欣赏这个程序的布局。默认情况下，代码在上半部分，功能区标签在下半部分。这可以让你访问终端的输出、上下文追踪器、断点列表、注册器地址、内存映射和变量控制。但是请注意在“Edit”-“Preferences”-“Layout”下你可以选择不同的布局，包括一个可以修改的动态布局。

自然，当你设置了全部断点，观察点和布局，您可以在“File”菜单下很方便地保存该会话，以便你下次打开时恢复。

Nemiver的高级用法

到目前为止，我们讨论的都是Nemiver的基本特征，例如，你马上开始调试一个简单的程序需要了解什么。如果你有更高的需求，特别是对于一些更加复杂的程序，你应该会对接下来提到的这些特征更感兴趣。

调试一个正在运行的进程

Nemiver允许你驳接到一个正在运行的进程进行调试。在“File”菜单，你可以筛选出正在运行的进程，并驳接到某个进程。

通过TCP连接远程调试一个程序

Nemiver支持远程调试，你可以在一台远程机器上设置一个轻量级调试服务器，然后你在另外一台机器上启动 nemiver 去调试运行在调试服务器上的程序。如果出于某些原因，你不能在远程机器上很好地驾驭 Nemiver或者GDB，那么远程调试对于你来说将非常有用。在“File”菜单下，指定二进制文件、共享库位置、远程地址和端口。

使用你的GDB二进制程序进行调试

如果你的Nemiver是自行编译的，你可以在“Edit（编辑）”-“Preferences（首选项）”-“Debug（调试）”下给GDB指定一个新的位置。如果你想在Nemiver下使用定制版本的GDB，那么这个选项对你来说是非常实用的。

跟随一个子进程或者父进程

当你的程序分支时，Nemiver是可以设置为跟随子进程或者父进程的。想激活这个功能，请到“Debugger”下面的“Preferences（首选项）”。

总而言之，Nemiver大概是我最喜欢的不在IDE里面的调试程序。在我看来，它甚至可以击败GDB，它和命令行程序一样深深吸引了我。所以，如果你从未使用过的话，我会强烈推荐你使用。我十分感谢它背后的开发团队给了我这么一个可靠、稳定的程序。

你对Nemiver有什么见解？你是否也考虑它作为独立的调试工具？或者仍然坚持使用IDE？让我们在评论中探讨吧。

via: http://xmodulo.com/debug-program-nemiver-debugger.html

作者：Adrien Brochard 译者：disylee 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出