【转】无调试器调试--使用调试宏

转自：https://www.hahack.com/wiki/tools-makefile.html#

调试器的出现固然极大地改善了可怜的程序员们的生活水平，然而调试器也并不总是扮演救世主的角色，例如，在有复杂竞争条件的多线程程序或者分布式程序中，调试器所能起的作用通常都不大。另外，调试运行和正常运行的程序实际上是有一定的差异的，有些神奇的 bug，当你以正常方式运行程序时，它跑出来作威作福，可以当你以调试模式运行程序的时候，它就躲得无影无踪了。更为极端的情况是没有调试器可以用，如果 gdb 的开发人员需要用 gdb 来调试 gdb 都还可以接受的话，那么 Linux kernel 的开发人员就真的是悲剧了。

因此，很多时候，我们需要在没有调试器的情况下进行调试，幸运的是，在这样的情况下，也是有一些约定的方法可以遵循的。

core dump

在 Linux 下，程序如果出现段错误退出，会产生 core dump 文件，默认情况下被 ulimit 禁用了这个功能，运行下面这个命令：

1	ulimit -c 5000

将允许系统产生 5kB 以内的 core dump 文件，可以根据自己的需求调整大小，并写到 shell 的启动脚本里。系统生成的 core dump 文件通常就是叫做 core，包含了程序出错时的整个状态，用 gdb 加载 core 文件:

1	gdb program core

就可以进行一些事后分析，例如，可以通过 backtrace 命令查出出错时的调用栈，并查看一些变量的值等，通常对于定位 bug 有很大的帮助。

printf 调试

printf 调试泛指通过记录程序执行状态来做调试的方法。具体来说，通常我们对于程序的行为和状态都有一些期望的值，通过将程序运行时的实际值打印出来，与期望的情况进行对比，就可以逐渐找到问题的所在。然而这种方法操作起来却有一些相当繁琐的地方:

首先，由于不知道问题出在哪里，又不能在所有的地方都添加输出语句(输出信息太多的话，要找到问题就变得困难了)，所以通常会在可疑的地方添加输出语句,！如果结果发现猜错了,就需要换一个地方或者扩大范围,修改代码,重新编译,运行,再查看新的输出结果。对于编译时间很长(例如,有很多模版代码的 C++程序)的情况,整个过程会变得相当痛苦,因为可能需要重复很多次,并且许多时间都是在做无聊的等待。其次,如果找到了问题所在,是不是要删除那些状态输出语句呢？过多的输出是会影响程序运行性能的，特别是打印到终端上。这些输出语句可能遍布代码的各个角落，要全部清除也不容易，而且，万一以后遇到了类似的 bug 呢?可能还要再写一遍这些类似的输出语句。另一个选择就是把他们注释掉。但是，无论如何，代码会被改得越来越乱。

避免让代码变乱的解决方案是使用标准化的工具，例如，最简单的情况，可以使用下面这样的一个宏:

#ifdef DEBUG
#define LOG(args) printf args
#else
#define LOG(args) ((void) 0)
#endif /* DEBUG */

需要记录信息的时候，使用

1	LOG(("a = %d, b = %d\n", a, b));

就可以了(注意双重括号是必要的)，需要调试的时候，只要定义 DEBUG，就可以得到调试输出，而调试结束之后可以直接去掉 DEBUG 的定义，这样 LOG 宏在编译的时候就会变成空语句，也就不会产生任何输出了。即使想要移除这些调试语句，由于它们都有统一的格式，因此也可以方便地进行自动化处理。

对于更为复杂的项目，可以使用一些第三方的成熟的日志库来满足更复杂的需求，实现更灵活的控制。

总的来说， printf 调试主要用在两种情况下:

过于简单的情况：懒得启动调试器了。
过于复杂的情况：调试器已经无能为力了，例如一些分布式的程序。

assert 断言

程序一般分为 Debug 版本和 Release 版本, Debug 版本用于内部调试, Release 版本发行给用户使用。

断言 assert 是仅在 Debug 版本起作用的宏，它用于检查“不应该”发生的情况，为程序增加诊断功能。

1	void assert(int expression)

当assert(expression)执行时，如果表达式的值为0，那么 assert 宏将在标准出错输出流 stderr 输出一条如下所示的信息：

1	Assertion failed: 表达式， file 文件名， line nnn

然后调用 abort 终止执行。其中的源文件名和行号来自于预处理程序宏 __FILE__ 和 __LINE__ 。

如果在头文件 assert.h 被包含时定义了宏 NDEBUG，那么宏 assert 将被忽略。

下例是一个内存复制函数。在运行过程中,如果 assert 的参数为假，那么程序就会中止(一般地还会出现提示对话,说明在什么地方引发了 assert)。

void *memcpy(void *pvTo, const void *pvFrom, size_t size)
{assert((pvTo != NULL) && (pvFrom != NULL)); // 使用断言byte *pbTo = (byte *) pvTo;  // 防止改变 pvTo 的地址byte *pbFrom = (byte *) pvFrom;    // 防止改变 pvFrom 的地址while(size -- > 0 )*pbTo ++ = *pbFrom ++ ;return pvTo;
}

在程序里许多地方插入断言也没有关系，断言在正常的时候并不会产生输出，而且在去掉调试选项之后，断言会编译为空语句，不会影响最终程序的性能。另外，断言通常是对程序状态的一个客观描述，还可以起到注释的作用。因此在代码中保留合适的断言是比较推荐的做法。

断言出错之后立即退出，而 printf 则需要事后再去分析和寻找问题。然而太过于暴力也算是断言的一个缺点，因为 bug 有大小疾缓，有时候让程序能持续稳定地运行也是很重要的，因此除非特别严重的时候，人们通常会倾向于使用更加温和的记录日志的方式来记录下潜在的 bug，而不是直接结束程序。

使用断言的规则：

使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别，后者是必然存在的并且是一定要作出处理的。
在函数的入口处,使用断言检查参数的有效性(合法性)。
在编写函数时,要进行反复的考查,并且自问：“我打算做哪些假定?”一旦确定了的假定,就要使用断言对假定进行检查。
一般教科书都鼓励程序员们进行防错设计，但要记住这种编程风格可能会隐瞒错误。当进行防错设计时，如果“不可能发生”的事情的确发生了，则要使用断言进行报警。

func 变量

在打印调试信息时除了文件名和行号之外还可以打印出当前函数名，C99引入一个特殊的标识符__func__支持这一功能。这个标识符应该是一个变量名而不是宏定义，不属于预处理的范畴，但它的作用和__FILE__、__LINE__类似，所以放在一起讲。例如：

#include <stdio.h>void myfunc(void)
{printf("%s\n", __func__);
}int main(void)
{myfunc();printf("%s\n", __func__);return 0;
}

输出：

$ gcc main.c
$ ./a.out
myfunc
main

调试宏

Mongrel 的作者 Zed A. Shaw 编写了一个更为实用的调试宏，内容只有如下短短几行：

#ifndef __dbg_h__
#define __dbg_h__#include <stdio.h>
#include <errno.h>
#include <string.h>#ifdef NDEBUG
#define debug(M, ...)
#else
#define debug(M, ...) fprintf(stderr, "DEBUG %s:%d: " M "\n", __FILE__, __LINE__, ##__VA_ARGS__)
#endif#define clean_errno() (errno == 0 ? "None" : strerror(errno))#define log_err(M, ...) fprintf(stderr, "[ERROR] (%s:%d: errno: %s) " M "\n", __FILE__, __LINE__, clean_errno(), ##__VA_ARGS__)#define log_warn(M, ...) fprintf(stderr, "[WARN] (%s:%d: errno: %s) " M "\n", __FILE__, __LINE__, clean_errno(), ##__VA_ARGS__)#define log_info(M, ...) fprintf(stderr, "[INFO] (%s:%d) " M "\n", __FILE__, __LINE__, ##__VA_ARGS__)#define check(A, M, ...) if(!(A)) { log_err(M, ##__VA_ARGS__); errno=0; goto error; }#define sentinel(M, ...)  { log_err(M, ##__VA_ARGS__); errno=0; goto error; }#define check_mem(A) check((A), "Out of memory.")#define check_debug(A, M, ...) if(!(A)) { debug(M, ##__VA_ARGS__); errno=0; goto error; }#endif

将它保存为 dbg.h 就可以在需要调试的地方引入该文件然后调用预定义的几个调试函数：

debug：当没有预定义 NDEBUG 宏时，调用形如 debug("format", arg1, arg2) 的语句将可以像 fprintf 一样输出内容到 stderr。如果预定义了 NDEBUG ，则调用 debug 函数将不会产生任何输出；
clean_errno：获得一个更安全且可读的 errno 版本。通常作为其他几个调试函数的参数；
log_err、log_warn、log_info：产生日志输出。和 debug 函数类似，但是不能通过设置 NDEBUG 来跳过执行；
check：非常有用的宏，可以检查条件 A 是否成立。如果不成立，将错误 M 输出到日志（利用 log_err 宏），并跳转到函数的错误处理部分（使用 error: 标号标记的语句段）。
sentinel：另一个实用的宏。用于放到一个不该被执行的函数里面。如果该函数被执行，则会打印一个错误信息，并跳转到函数的错误处理部分 error: 。常用的用法是将它放到 if 语句或 switch 语句中不该执行的边界条件里，例如 default: 语句段中；
check_mem：确保一个指针是有效的指针（不是空指针），如果该指针为空，则提示“Out of memory.”错误信息；
check_debug：和 check 类似，但是底层执行的是 debug 宏而非 log_err 宏，因此可以通过设置 NDEBUG 来禁用这些输出，但仍然会进行错误检查和处理。

总结

在绝大多数的情况下，使用调试宏来诊断和修复跟逻辑语句相关的错误。
使用 Valgrind 来捕捉所有跟内存相关的错误；
对于上面两个工具无法解决的诡异问题，或者在某些紧急的场合被逼尽可能多的获取错误相关信息的时候，才使用 gdb 。