每年二月末到三月初，公司都会安排一批实习生到各个部门实习。虽说去年经济危机了，但公司的实习生数量似乎并没有减少。起码我们部门"新同事"的数量基本与去年持平。按惯例，每位新同事都会有一名导师，与此同时各个部门还会根据自身的业务特点对这批学生进行有针对性的集中培训和交流。比起我入司那会儿，现在的实习生已经算是幸福多了。我那会儿实习生人数少，部门没有安排什么培训，完全靠导师安排自己努力学习。此次培训的内容是经过老员工们讨论和对新员工的需求调查后才确定的。其中新同事们普遍对如何进行程序调试这块比较感兴趣，我负责准备和实施了这个题目。虽说有过几年调试程序的经验，但是自已也没有系统的总结过，这次培训后顺便在这里做一下总结和记录。

说到程序员，各位大脑中第一反应就是编码；但我们知道软件开发可不仅仅只有编码，调试也占据了程序员很大一部分精力。程序员"简单"的工作中，80%的时间都是在编码和调试(现在文档工作也不少)。调试的对象是BUG，BUG是什么呢？BUG就是编码过程的伴生品。既然将之诠释为"伴生品"，那就意味着"凡是软件，内必有BUG"。也许有人不同意这样的观点，但无关大碍，因为如何看待BUG本身就可以看成是一个哲学范畴的话题，大可见仁见智。

调试前，首先做好心理准备。
调试BUG的过程可以用"艰苦卓绝"来形容；特别是一些"又臭又硬"的BUG，难于重现，难于定位，甚至在投入相当大的精力后仍然无法Fix。所以调试BUG前就要摆正心态，要保持清醒、保持耐心，甚至要做好打"持久战"的打算。要知道Unix下还有一些BUG也是在隐藏了几十年后才被Fixed。

预防BUG的发生，降低BUG发生概率。
我们还需要清醒的认识到：事实证明与编码相比，调试BUG的成本是更高的。BUG可简单分为产品Release前BUG和Release后的BUG。无论哪一种，你都要经历收集数据、重现BUG、定位问题、修正问题和Accepted等多个步骤后才能重新Release。这其中以Release后的BUG花费的成本为更高。既然如此，我们何不采用一些手段来相对的预防BUG的发生，降低BUG发生的概率呢！这里说说我想到的。从一个软件的整个生命周期来看，保证软件质量应从需求开始，但这里我们主要关注编码阶段。从个体开发者角度我们可以从以下三个方面考虑：

* 充分的静态代码检查
充分利用你手头上的工具对你编写的代码做严格的检查，这些工具包括编译器(尽可能将警告级别提升到你可以接受的最高级别)、LINT工具等。这将帮你将代码中潜在的细小问题发掘出来，避免这些问题在事后成为隐藏的大BUG。

* 调试版添加断言
充分利用断言Assertions这把发现BUG的利器，借鉴契约式编程的一些规则，在你的调试版代码中适当的地方添加Assertions。这样的方法同样可以帮助你及时发现代码中隐藏的缺陷。

* 充分的单元测试
充分的单元测试提高代码覆盖率，减少业务逻辑遗失导致的BUG；单元测试用例还可以结合断言发现更多程序潜在问题。如果能做到测试先行，也许效果会更好。

* 代码同级评审
让其他人来审核你的代码，提前帮你发现潜在的问题；如果能做到结对编程，也许效果会更好。
 
从组织的角度来看，持续集成的实践可以让组员更加及时的发现编码阶段的问题，不让问题遗漏到后面阶段成为严重BUG。

如果很好的实施了上述这些手段后，你的BUG发生率会大大降低，但是前面说过：BUG不能避免，一旦BUG发生了，该怎么办？其实与BUG做艰苦卓绝的斗争，也是有一定方法的。

* 收集"现场数据"
BUG是表象，我们要发现内部原因还是需要更多的表象数据去推理。我们需要收集到足够的"现场数据"。比较初级的、基本的、也是被大家常用的方法就加print语句，将BUG现场周围的"证据"输出到屏幕上或者文件中，这样你能更直观的看到；当然我这里是不推荐Print语句的，因为不够专业、不够高效；拿起你的源代码调试工具，诸如GDB来完成这一功能吧；有时候现场数据可以通过你的程序运行日志而直接得到这样就更简单了，调试阶段这种日志要保持尽量详细且必要；如果是运行在客户现场的程序，你无法添加Print，也无法GDB调试，那么你需要在测试环境下重现BUG表象，然后再利用工具收集数据。重现BUG表象多数情况较容易，但是也不乏找不到重现条件的时候；这时候你就只能根据已有的运行日志等通过"顺藤摸瓜"的业务逻辑分析去"猜测"可能的重现步骤，逐一尝试，做好尝试记录，隔一段时间对记录进行分析，找出一些"蛛丝马迹"，也许会帮助你节省些时间。

* 定位问题所在
有了"现场数据"，需要你用"火眼金睛"从这一堆数据中找出你真正需要的；如果无法直接识别出真数据，那么可以根据数据做几组不同数据组合的模拟测试，在数据变化中"去伪存真"，找到那个"真悟空"。有了信赖的真实数据，你一般都可以根据代码逻辑推理出问题所在。但有些时候还是需要通过隔离代码、缩小嫌疑代码范围等方法才能锁定一些较难BUG的具体问题所在。

* Fix and Test
既然找到问题所在了，那剩下的工作就是修正它并重现验证；新用例同时也补充了你的单元测试用例库。如果修正失败，那就从头开始新一轮分析过程吧。

BUG真的是种类繁多，情况多样。 上面也仅仅是一些常见BUG解决过程的体会。如果你已经在一个BUG上整整消耗了一天时间了，那么建议你休息一会儿，小憩一会儿，甚至是睡一觉到天亮。也许梦中你会发现问题所在。要知道大脑潜意识是会帮助我们的，估计很多人都有过类似经历，不是吗？

定期回顾你自己"出产"的BUG列表，你会发现很多BUG是你在预防阶段做的不够好而导致的，特别是一些涉及内存操作的BUG，如果前期预防工作没有做好的话，那么后期解决BUG花费的精力会很多；定期回顾还有一个好处就是强化你的思维意识，让你以后尽量不再犯同一个错误。

C语言程序员在平时工作中，到底如何获取成就感呢？我几乎可以肯定的是：找到一个隐藏已久，多年无人发现的大Bug肯定可以归属到C程序员成就感的范畴中。与操作系统斗、与编译器斗、与内存斗，其乐无穷吗^_^。

今天测试人员在进行平台迁移测试时发现一个致命的问题，导致系统不能正常工作。问题提到我这，为了不耽误测试进度，马上丢下手头的工作开始问题的查找，经过GDB多次跟踪调试，终于发现了一隐藏多年的问题，至于能否称为Bug呢，我还不敢确定，因为我尚不清楚当年的前辈们在书写这些代码时到底是如何考虑的。

前不久听说隐藏在FreeBSD系统中长达25年的一个Bug终于被Fixed了，当然今天我发现的这个问题肯定不及FreeBSD的这个Bug重要，但是对于我们的产品来说还是有很大意义的。

其实这个问题很简单，这里简单用一个例子来展示这个问题(稍后我还会用这个例子做进一步深入分析)：
/* TestFoo.c 注意该文件并不一定在所有编译器下都能顺利编译通过，警告是不可避免的了 */

typedef struct Foo {
        int     a;
        int     b;
        int     c;
} Foo;

int main() {
        Foo f;
        f.a = 17;
        f.b = 23;
        f.c = 19;

        test_foo(f);
}

void test_foo(Foo *pfoo) {
        pfoo->c = 29;
}

明眼人一眼就能看得出来，test_foo调用时，没有按照test_foo的原型传入f的地址，而是将f以值得形式传给了test_foo这个函数。就是这样的一个很低级的问题。当然了如果一个系统只有几行代码的话，这个问题可能会马上暴露出来；但是在一个拥有几十万行代码且稳定运行了若干年的系统中，没人会注意这个问题。

有人马上会提出两个疑问：
1) 为什么编译器没能给出参数类型不匹配的警告？
2) 为什么系统能在这样明显的问题下稳定运行若干年而不出错呢？

首先回答第一个问题：之所以编译器没能给出警告是因为项目遗留代码不规范的缘故，在调用test_foo这个角色函数的C文件中并没有引用test_foo原型声明所在的头文件，更不专业的是：test_foo这个函数根本没有在任何头文件中给予原型声明；这样一来，编译器在编译阶段无从知道test_foo到底是个什么样子的函数，也就无法给出正确的调用检查了。而在链接阶段根本不对参数进行有效检查，导致漏洞得以延续。

第二个问题也是今天在发现这个问题后我最最疑惑的了。按理论上分析，如果按照上述例子中代码，f以值传递方式传入test_foo，test_foo会将f的头4个字节转换成一个Foo指针类型，这样在test_foo中引用pfoo时实际上访问的地址应该是0×11(17d)，这个地址在应用程序进程地址空间属于系统地址空间，用户根本无法访问，一旦访问势必违法，如果在SUN SPARC平台上势必是要崩core的。但是实际情况是这样吗？我将上述程序放到SPARC Solaris9平台上用GCC 3.2版本编译器编译后，居然执行后一切OK。而这个源代码放到X86 Solaris 10上用GCC 3.4.6编译后(如果想编译成功，需要将test_foo的返回值改成int)运行就会出Core。初步得出结论：不同CPU体系对该种代码的处理有不同，需逐一分析。

先来看看SPARC Solaris9，用GDB跟踪程序：
Starting program: a.out

Breakpoint 1, test_foo (pfoo=0xffbff0c0) at TestFoo.c:20
20              pfoo->c = 29;
(gdb) up
#1  0x0001069c in main () at TestFoo.c:15
15              test_foo(f);
(gdb) p &f
$1 = (Foo *) 0xffbff0d0

可以看到在main中，f的地址是0xffbff0d0，而传入test_foo后，pfoo指向的地址居然是0xffbff0c0了。一个推翻前面推理的猜想：编译器在栈上复制了一份f，得到了f'，并将f'的地址传给了test_foo。但是编译器为什么要这么做呢？似乎是当编译器发现传入函数的实际参数的值类型大于形式参数类型的时候，都要这么来做，这里我也没有什么特殊的根据，只是通过实验得出这个结论。比如：

/* testvaluepass.c */
typedef struct Foo {
        int     a;
        int     b;
        int     c;
} Foo;

int main() {
        Foo     f;
        f.a     = 17;
        func(f);
}

void func(int x) {
        x = 7;
}

/* testvaluepass.s , <=gcc -S testvaluepass.c*/
main:
        !#PROLOGUE# 0
        save    %sp, -144, %sp        // 寄存器窗口切换（似乎是SPARC独有的机制），fp<- old_sp, new_sp <- old_sp – 144
        !#PROLOGUE# 1
        mov     17, %o0
        st      %o0, [%fp-32]        //%fp-32 &f.a

        ldd     [%fp-32], %o0
        std     %o0, [%fp-48]        //从%fp-48开始，复制f得到f'，先copy一个dword，再来一个word，一共12个字节
        ld      [%fp-24], %o0
        st      %o0, [%fp-40]

        add     %fp, -48, %o0        //将f'的地址存入%o0，在subroutine func中, %o0随着寄存器窗口的变动，新栈帧中%i0等于old栈帧中的%o0，也就是f'在栈上的首地址
        call    func, 0
         nop
        mov     %o0, %i0
        nop
        ret
        restore

func:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
        !#PROLOGUE# 1
        st      %i0, [%fp+68]        //将f'地址写入本地变量x中
        mov     7, %i0
        st      %i0, [%fp+68]        //将7赋值给x
        nop
        ret
        restore

有了这个例子之后，我们可以分析第一个例子了，同样也是在经过汇编之后：
main:
        !#PROLOGUE# 0
        save    %sp, -144, %sp
        !#PROLOGUE# 1
        mov     17, %o0
        st      %o0, [%fp-32]
        mov     23, %o0
        st      %o0, [%fp-28]
        mov     19, %o0
        st      %o0, [%fp-24]

        ldd     [%fp-32], %o0        //这四行语句在重新复制一个f
        std     %o0, [%fp-48]
        ld      [%fp-24], %o0
        st      %o0, [%fp-40]

        add     %fp, -48, %o0         //将新f'的地址放到%o0中，而不是将[%fp-48]存入%o0，关键啊！
        call    test_foo, 0
         nop
        mov     %o0, %i0
        nop
        ret
        restore

test_foo:
        !#PROLOGUE# 0
        save    %sp, -112,         // 寄存器窗口切换，fp<- old_sp, new_sp %i0
        !#PROLOGUE# 1
        st      %i0, [%fp+68]          //%i0存储的是f’的地址，是在save时由%o0得来的，存入[%fp+68]，即形式参数变量在栈上的地址。而恰好的是这个参数还是一个Foo*类型，这也是在SPARC上没出错的原因了。
        ld      [%fp+68], %i1        //%i此时存储的是f'的地址, 这个就是gdb跟踪时的0xffbff0c0
        mov     29, %i0
        st      %i0, [%i1+8]        //将29存入f'.c里面去了
        nop
        ret
        restore

这样一来，没有出core的原因也就找到了，但是编译器为何如此做，还无法得出确切结论。

前面说过，在X86平台上，第一个例子程序是出core的，我们同样也来看看x86平台下的汇编码(与SPARC不同，esp一直在动)：
.globl main
        .type   main, @function
main:
.LFB2:
.LM1:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp        //ebp <- old sp
.LCFI1:
        subl    $24, %esp        
.LCFI2:
        andl    $-16, %esp        
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
.LM2:
        movl    $17, -24(%ebp)        //f.a  init %ebp-24
.LM3:
        movl    $23, -20(%ebp)        //f.b  init %ebp-20
.LM4:
        movl    $19, -16(%ebp)        //f.c  init %ebp-16
.LM5:
        subl    $4, %esp
        pushl   -16(%ebp)        //push onto stack, as first parameter
        pushl   -20(%ebp)
        pushl   -24(%ebp)       
.LCFI3:
        call    test_foo
        addl    $16, %esp
.LM6:
        leave
        ret
test_foo:
.LFB3:
.LM7:
        pushl   %ebp            //save old ebp
.LCFI4:
        movl    %esp, %ebp        //current ebp <- old esp
.LCFI5:
.LM8:
        movl    8(%ebp), %eax        //eax <- ebp + 8 ，将ebp+8那块内存的值放到%eax，而这个值恰好是0×11(17d)
        movl    $29, 8(%eax)        //访问0×11+8显然不合理，出core

看来，不同平台的编译器生成代码差异还是不小的，但是在系统里发现的这个问题到底是否定性为Bug呢?也许这样的一个问题在早期的实现者头脑里早已经是已知的了，他可能就是故意这么做的。如果真的是这样的话，那还真不能算作一个bug，而是我们水平太浅，没能意识到这点。但可以肯定的是是这样编写代码绝对是一个不好的代码风格和习惯。另外发现代码中除了这一处之外还有多处相类似的调用，多是将变量值直接付给一个地址参数了。

附:  SPARC汇编笔记