项目背景

某天在用C++做一个feature的时候，发现一个对象的成员变量无论如何都写不对，而用gdb调试之，竟然发现print出来值又是对的…… 为了最简化这个bug的背景，我在github上直接创建了一个简化的repo，大家可以看看。

简单来说，这个项目的结构大致如下：

cpp-debug-01/
├── App.h
├── Base1.h
├── Base.h
├── Child.cpp
├── Child.h
├── main.cpp
└── Makefile

编译完之后，运行编译出来的./test_app就会输出下面的crash信息：

test_app: Child.cpp:11: SuperChild::SuperChild(unsigned int*): Assertion `data != __null' failed.
Aborted (core dumped)

OK，既然crash了，那我们来看看出问题的代码(Child.cpp)：

1
2
3
4
5
6
7
8
9
10
11
12
#include "Child.h"
#include "App.h"
#include <cstdio>

#include <cassert>


SuperChild::SuperChild(unsigned* d)
: Child(0, d, 1)
{
    assert(data != NULL);
}

data是SuperChild的父类Child的一个protected成员，所以说明data没有初始化？

1
2
3
4
5
6
7
// Child构造函数定义
Child(unsigned s, unsigned* d, int i)
{
    seq = s;
    data = d; // <<<<
    i_data = i;
}

咦？代码中明明初始化了啊，怎么会是NULL呢？难道我穿进来的这个d指针的值不对？看来要祭出gdb这个杀器才行。

gdb调试

我们gdb一下我们的程序，在main函数调用SuperChild那设一个断点好了。

airekans@test-host:~/programming/test/cpp-debug-01$ gdb -q ./test_app 
Reading symbols from ~/programming/test/cpp-debug-01/test_app...done.
(gdb) b main.cpp:8
Breakpoint 1 at 0x40052d: file main.cpp, line 8.
(gdb) run
Starting program: ~/programming/test/cpp-debug-01/test_app 
Breakpoint 1, main () at main.cpp:8
8	    SuperChild c1(&i);
(gdb)

太好了，我们看看现在穿进去的这个指针的值：

(gdb) p i
$1 = 345
(gdb) p &i
$2 = (unsigned int *) 0x7fffffffdc6c

嗯，一切正常的样子。我们继续进去SuperChild的构造函数看看：

(gdb) s
SuperChild::SuperChild (this=0x7fffffffdc40, d=0x7fffffffdc6c) at Child.cpp:9
9	: Child(0, d, 1)
(gdb) p d
$3 = (unsigned int *) 0x7fffffffdc6c

我打印了一下穿进来的指针d，值是对的。好的，那我们进去父类Child的构造函数继续看：

(gdb) s
Child::Child (this=0x7fffffffdc40, s=0, d=0x7fffffffdc6c, i=1) at Child.h:10
10	    {
(gdb) n
11	        seq = s;
(gdb) n
12	        data = d;
(gdb) n
13	        i_data = i;
(gdb) p d
$4 = (unsigned int *) 0x7fffffffdc6c
(gdb) p data
$5 = (unsigned int *) 0x7fffffffdc6c
(gdb) p this->data
$6 = (unsigned int *) 0x7fffffffdc6c

嗯，构造函数已经把这个指针的值赋给了成员data。而我也确认了指针和成员的值都是对的。嗯，看起来程序都很正常，难道刚才的crash只是个美丽的误会？哈哈哈哈，好吧，试一下继续好了：

(gdb) c
Continuing.
test_app: Child.cpp:11: SuperChild::SuperChild(unsigned int*): Assertion `data != __null' failed.
 
Program received signal SIGABRT, Aborted.
0x00007ffff7a51425 in raise () from /lib/x86_64-linux-gnu/libc.so.6

啊？assert还是失败了？先看看data的值……

#4  0x00000000004005e8 in SuperChild::SuperChild (this=0x7fffffffdc40, 
    d=0x7fffffffdc6c) at Child.cpp:11
11	    assert(data != NULL);
(gdb) p data
$7 = (unsigned int *) 0x0

data竟然是0！！！天啊，难道我遇见了薛定鄂的bug？！刚才明明还是正常的啊，为什么这里就变成0了呢…… 是谁改变了我的data啊？

要看数据怎么变化，看来这次是要用数据断点了。

数据断点

重启在gdb里面运行一次程序，这次我们到了Child的构造函数里面之后，对于data成员设定一个数据断点看看：

(gdb) p &data
$14 = (unsigned int **) 0x7fffffffdc50
(gdb) watch *(unsigned*) 0x7fffffffdc50
Hardware watchpoint 4: *(unsigned*) 0x7fffffffdc50

可以看到data成员的地址是0x7fffffffdc50，然后我们看看在Child里面设置的时候会不会停下来：

(gdb) c
Continuing.
Hardware watchpoint 4: *(unsigned*) 0x7fffffffdc50
 
Old value = 0
New value = 4294958188
Child::Child (this=0x7fffffffdc40, s=0, d=0x7fffffffdc6c, i=1) at Child.h:13
13	        i_data = i;

嗯，停下来的，说明的确是改变了值，我们查看一下，确认一下：

(gdb) p d
$15 = (unsigned int *) 0x7fffffffdc6c
(gdb) p data
$16 = (unsigned int *) 0x7fffffffdc6c

好的，那从Child返回之后，我们再看看。是没有停下来的，说明数据没有被改变。这个时候我们来看看data的值：

(gdb) n
SuperChild::SuperChild (this=0x7fffffffdc40, d=0x7fffffffdc6c) at Child.cpp:11
11	    assert(data != NULL);
(gdb) p data
$17 = (unsigned int *) 0x0

！！！T_T 是见鬼了吗，明明连数据断点都没有触发啊，但是为什么值会改变了啊……

连数据断点都不管用了，这回我只能老老实实的乖乖看汇编代码了……

反汇编

用gdb里面的disassemble可以用来查看当前栈帧的函数反汇编结果。下面我们来看看SuperChild的构造函数的汇编(只看到assert调用)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
(gdb) disassemble 
Dump of assembler code for function SuperChild::SuperChild(unsigned int*):
   0x0000000000400598 <+0>:	push   %rbp
   0x0000000000400599 <+1>:	mov    %rsp,%rbp
   0x000000000040059c <+4>:	sub    $0x10,%rsp
   0x00000000004005a0 <+8>:	mov    %rdi,-0x8(%rbp)
   0x00000000004005a4 <+12>:	mov    %rsi,-0x10(%rbp)
   0x00000000004005a8 <+16>:	mov    -0x8(%rbp),%rax
   0x00000000004005ac <+20>:	mov    -0x10(%rbp),%rdx
   0x00000000004005b0 <+24>:	mov    $0x1,%ecx
   0x00000000004005b5 <+29>:	mov    $0x0,%esi
   0x00000000004005ba <+34>:	mov    %rax,%rdi
   0x00000000004005bd <+37>:	callq  0x400552 <Child::Child(unsigned int, unsigned int*, int)>
=> 0x00000000004005c2 <+42>:	mov    -0x8(%rbp),%rax
   0x00000000004005c6 <+46>:	mov    0x8(%rax),%rax
   0x00000000004005ca <+50>:	test   %rax,%rax
   0x00000000004005cd <+53>:	jne    0x4005e8 <SuperChild::SuperChild(unsigned int*)+80>
   0x00000000004005cf <+55>:	mov    $0x400720,%ecx
   0x00000000004005d4 <+60>:	mov    $0xb,%edx
   0x00000000004005d9 <+65>:	mov    $0x400700,%esi
   0x00000000004005de <+70>:	mov    $0x40070a,%edi
   0x00000000004005e3 <+75>:	callq  0x400400 <__assert_fail@plt>
   0x00000000004005e8 <+80>:	leaveq 
   0x00000000004005e9 <+81>:	retq

从代码中我们看到第11行是callq，也就是调用Child的构造函数。而第15行则是一个jne指令，后面的地址是SuperChild构造函数加80，我们看到是构造函数的结束的地方。这有点奇怪，SuperChild的构造函数只有一个assert，怎么会出现经常在if里面才有的jne指令呢？

其实assert的实现正是用的一个if。可以在/usr/include/assert.h里面看到通常情况下的assert是一个宏(各个版本的libc的实现可能会有稍微的差别)：

# define assert(expr)							\
  ((expr)								        \
   ? __ASSERT_VOID_CAST (0)						\
   : __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))

这解释了上面的jne指令。所以jne之前的应该是载入data成员的值的汇编语句。所以关键的就是下面的这几句：

1
2
3
mov    -0x8(%rbp),%rax
mov    0x8(%rax),%rax
test   %rax,%rax

这几句的意思对应着下面的C++语句：

this->data

首先我们知道，this指针在C++里面实际上是相当于第一个参数传递进成员函数的，就算构造函数也不例外。而-0x8(%rbp)存放在什么值呢？我们看到在上面的第6行，有这么一句：

mov    %rdi,-0x8(%rbp)

哦，原来是从rdi寄存器赋值过来的。而rdi在x64的函数调用规则里面是用来在函数调用的时候，存放第一个整形(或者指针)参数的。(这里多说一句，由于我机器是64位的，所以汇编跟32位的会有差别) 哦？那就正好是this指针也！太好了，那么就是说现在rax就已经放着this指针了。接下来的一句mov 0x8(%rax),%rax，就是说从this的地方位移8的地方取出值。嗯，这正好就是data的偏移值。看起来没什么问题。好吧，取值的地方没问题，那我们看看赋值到data的地方吧，也就是Child的构造函数。

Child构造函数

我们看看Child的构造函数的汇编代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
   0x0000000000400552 <+0>:	push   %rbp
   0x0000000000400553 <+1>:	mov    %rsp,%rbp
   0x0000000000400556 <+4>:	sub    $0x20,%rsp
   0x000000000040055a <+8>:	mov    %rdi,-0x8(%rbp)
   0x000000000040055e <+12>:	mov    %esi,-0xc(%rbp)
   0x0000000000400561 <+15>:	mov    %rdx,-0x18(%rbp)
   0x0000000000400565 <+19>:	mov    %ecx,-0x10(%rbp)
   0x0000000000400568 <+22>:	mov    -0x8(%rbp),%rax
   0x000000000040056c <+26>:	mov    %rax,%rdi
   0x000000000040056f <+29>:	callq  0x400548 <Base::Base()>
   0x0000000000400574 <+34>:	mov    -0x8(%rbp),%rax
   0x0000000000400578 <+38>:	mov    -0xc(%rbp),%edx
   0x000000000040057b <+41>:	mov    %edx,0x8(%rax)
=> 0x000000000040057e <+44>:	mov    -0x8(%rbp),%rax
   0x0000000000400582 <+48>:	mov    -0x18(%rbp),%rdx
   0x0000000000400586 <+52>:	mov    %rdx,0x10(%rax)
   0x000000000040058a <+56>:	mov    -0x8(%rbp),%rax
   0x000000000040058e <+60>:	mov    -0x10(%rbp),%edx
   0x0000000000400591 <+63>:	mov    %edx,0x18(%rax)
   0x0000000000400594 <+66>:	leaveq 
   0x0000000000400595 <+67>:	retq

嗯，根据上面的经验，第10行是调用父类的构造函数。而接下来的6行，每3行对应着C++中的一个赋值语句。那么我们关注一下data成员的赋值：

mov    -0x8(%rbp),%rax
mov    -0x18(%rbp),%rdx
mov    %rdx,0x10(%rax)

第一行是载入this指针到rax寄存器，第二行是将d的值载入到rdx。所以第三行的就是将d的值赋给data成员。等等，咦？为什么data会是0x10(%rax)？上面在SuperChild里面，明明data是0x8(%rax)啊！怎么会相差了8的位移呢？

为什么会位移不一样呢？是父类的size不对吗？怎么能够看见父类的size呢？

模板静态断言

为了能够判断一个类的大小，一般来说就使用sizeof来看了。比如说像下面这样：

std::cout << sizeof(Base) << std::endl;

但是这得在运行期才能看得见，而我希望在编译的时候就能够看见，有没有什么办法呢？是有的，在C++中，能够利用一个模板技巧来达到静态断言的效果。先来看看怎么做。我在Child的构造函数中利用静态断言来断言Base的大小为8，因为在Base.h里面就是两个unsigned的大小嘛，而每个unsigned大小是4。所以就有了下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template<unsigned size>
class TestSize;

template<>
class TestSize<8> {};

class Child : public Base
{
public:
    Child(unsigned s, unsigned* d, int i)
    {
        TestSize<sizeof(Base)> test_size;
        // ...
    }

上面的代码关键的就是模版TestSize。他利用了模板的偏特化特性，特化了一个只对8有效的特化类。而其他的值是没有办法产生对象的，因为其他的值并没有具体的定义。而在Child的构造函数里面，我们用sizeof(Base)来作为模板参数，所以只有当sizeof(Base)为8的时候，编译才可以通过，也这就是静态断言的一种用法。 (这种用法在“Modern C++ Design”有详细的介绍)

好吧，有了上面的断言，我们来编译一下：

g++ -g -c -o main.o main.cpp -I.
g++ -g -c -o Child.o Child.cpp -I.
In file included from Child.cpp:1:0:
Child.h: In constructor ‘Child::Child(unsigned int, unsigned int*, int)’:
Child.h:19:32: error: aggregate ‘TestSize<4u> test_size’ has incomplete type and cannot be defined
make: *** [Child.o] Error 1

哦！真的在Child.cpp编译出现了错误，可以看见对于Child.cpp来说，Base竟然大小是4，而不是8！

为什么会这样呢？明明main.cpp是没问题的，为什么Child.cpp却有问题呢？难道他们包含的Base不是同一个吗？

我们仔细看看main.cpp的头文件包含：

#include "App.h"
#include "Child.h"

然后我们再来看看Child.cpp的头文件包含：

#include "Child.h"
#include "App.h"

发现对于App.h和Child.h的包含顺序是反过来的。那么这两个头文件有什么玄机呢？我们看看App.h：

#include "Base.h"
#include "Child.h"

嗯，在头文件的部分，是先include的Base.h，然后include的Child.h。那Child.h呢？

#include "Base1.h"

咦？Child.h竟然include了一个Base1.h？这是啥？跟Base.h有什么关系？我们来看看Base.h和Base1.h的diff：

--- Base.h	2014-03-17 23:19:05.980027339 +0800
+++ Base1.h	2014-03-17 23:19:05.980027339 +0800
@@ -1,11 +1,10 @@
 #ifndef _BASE_H_
 #define _BASE_H_
 
 class Base
 {
 protected:
     unsigned u_data;
-    unsigned m_data;
 };
 
 #endif

好嘛，Base1.h除了少了一个m_data之外，竟然其他都全部一样的！！这回真相大白了。

Bug分析

为什么上面的Base1.h会导致bug呢？首先Base1.h和Base.h基本一样，连include guard都一样。然后我们看出问题的Child.cpp的include链是什么样子的(顺序按从左到右)：

Child.cpp
   |     \
Child.h  App.h
   |      |   \
Base1.h Base.h Child.h

由于Base1.h和Base.h的include guard是一样的，所以由于Base1.h在Base.h之前include，所以只会include Base1.h，而Base.h的内容会直接被忽略。所以对于Child.cpp来说，整个SuperChild的继承体系是这样的(我把成员写在类名的后面)：

SuperChild []
    |
  Child [seq, data, i_data]
    |
  Base (in Base1.h) [u_data]

好吧，那对于main.cpp来说呢？include链就会是下面的样子：

  main.cpp
   |     \
 App.h    Child.h
   |   \        \
Base.h Child.h  Base1.h

这里因为Base.h在Base1.h的前面，所以Base1.h就直接被忽略了。所以从main.cpp的角度来看，SuperChild的继承体系就是这个样子：

SuperChild []
    |
  Child [seq, data, i_data]
    |
  Base (in Base.h) [u_data, m_data]

看见了吧？从两个不同的编译单元来看，这个SuperChild的大小根本就是不一样的！最直接的原因就是Base被定义在两个不同的头文件，而且大小也不一样，导致了在Child的构造函数中，看见的data成员的偏移值和在SuperChild中看见的是不一样的。这就导致了我们说的这个bug。

首先从main.cpp看见的Child类，我们看看他的内存布局：

起始地址    成员    类型   
  | u_data | unsigned
  | m_data | unsigned
  |  seq   | unsigned
 | data   | unsigned*
 | i_data | int

而对于Child.cpp看见的Child类，内存布局是下面这样的：

起始地址    成员    类型   
  | u_data | unsigned
  |  seq   | unsigned
  | data   | unsigned*
 | i_data | int

所以在Child中的构造函数中赋值给data是会赋值到16这个偏移中的，而在SuperChild中取data，是会取到偏移8的，也就是对应到原来的seq的值。而我们在SuperChild给传的seq的初始值正正就是0。这终于解释了为什么在SuperChild的data的值总是0了。

这真是非常愚蠢的bug啊……但是一般愚蠢的bug，都需要极其变态的debug过程才能找的出来……

如何fix这个bug

其实修复这个bug非常简单……只需要把Child.h中的include "Base1.h"改成include "Base.h"，也就是无论如何都用Base.h就好了。

当然，这个bug的最主要的原因就是出现了Base1.h，这个很有可能是一个源文件的两个不同版本。这里就需要在用SCM的时候，更新的时候就直接修改源代码，不要copy一份，这样非常容易出问题……

同时，注意到google的c++编程规范中，给出了一个关于头文件的规定，其中有一个隐含单没有明说的规定，就是包含头文件的时候尽可能的不要用相对路径，而是直接从项目根目录一直写下来，比如common/base.h这样写，而不是base.h并加上-I的编译选项。这是在工程实践中非常重要的点，因为不用-I而是写全路径，可以加快编译速度，并且还可以最大程度的避免我遇到的这个bug。为什么这么说呢？因为如果出问题而相同的两个文件同名但在不同的目录下的话，如果在编译的时候利用-I选项是很可能在两个不同的编译单元包含了不同的头文件的。而如果用全路径的话，是完全不会出现这个bug。可以看到google的很多开源项目都是遵循这个规定的，比如protobuf。

一个插曲

不知道大家上面有没有注意到一个细节，就是下面的内存布局中，data的起始地址：

起始地址    成员    类型   
  | u_data | unsigned
  | m_data | unsigned
  |  seq   | unsigned
 | data   | unsigned*
 | i_data | int

为什么命名seq是一个unsigned类型，也就是大小是4的成员，但是data的对象的地址却比seq多了8。多了的4个byte去了哪里呢？其实对于有经验的人来说，很快就会猜到，这应该是padding造成的。但是padding不是一般是以4为单位的吗？这里刚好是4啊，不需要padding啊。

要注意到padding的单位是和CPU的word长度一致的，在32位系统上面，word的大小是4，所以padding也是4。但是在64位系统上，word的大小是8，这表示什么呢？这表示一个指针的大小是8 byte，并且他的地址必须是8的倍数。所以在上面的例子中，就产生了一个padding。具体的内存如下图所示：

0        4        8      12         16    24
| u_data | m_data | seq   | padding | data | i_data

至此，终于完成的修复并分析完了这个bug。

本作品由airekans创作，采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。

blog comments powered by Disqus

Published

11 March 2014

一次调试C++程序的艰苦历程