C++博客-loop_in_codes-随笔分类-c/c++

无锁有序链表的实现

Kevin Lynx — Tue, 05 May 2015 11:47:00 GMT

无锁有序链表可以保证元素的唯一性，使其可用于哈希表的桶，甚至直接作为一个效率不那么高的map。普通链表的无锁实现相对简单点，因为插入元素可以在表头插，而有序链表的插入则是任意位置。

本文主要基于论文High Performance Dynamic Lock-Free Hash Tables实现。

主要问题

链表的主要操作包含insert和remove，先简单实现一个版本，就会看到问题所在，以下代码只用作示例：

struct node_t {
        key_t key;
        value_t val;
        node_t *next;
    };

    int l_find(node_t **pred_ptr, node_t **item_ptr, node_t *head, key_t key) {
        node_t *pred = head;
        node_t *item = head->next;
        while (item) {
            int d = KEY_CMP(item->key, key);
            if (d >= 0) {
                *pred_ptr = pred;
                *item_ptr = item;
                return d == 0 ? TRUE : FALSE;
            }
            pred = item;
            item = item->next;
        } 
        *pred_ptr = pred;
        *item_ptr = NULL;
        return FALSE;
    }

    int l_insert(node_t *head, key_t key, value_t val) {
        node_t *pred, *item, *new_item;
        while (TRUE) {
            if (l_find(&pred, &item, head, key)) {
                return FALSE;
            }
            new_item = (node_t*) malloc(sizeof(node_t));
            new_item->key = key;
            new_item->val = val;
            new_item->next = item;
            // A. 如果pred本身被移除了
            if (CAS(&pred->next, item, new_item)) {
                return TRUE;
            }
            free(new_item);
        }
    }

    int l_remove(node_t *head, key_t key) {
        node_t *pred, *item;
        while (TRUE) {
            if (!l_find(&pred, &item, head, key)) {
                return TRUE;
            }
            // B. 如果pred被移除；如果item也被移除
            if (CAS(&pred->next, item, item->next)) {
                haz_free(item);
                return TRUE;
            }
        }
    }

l_find函数返回查找到的前序元素和元素本身，代码A和B虽然拿到了pred和item，但在CAS的时候，其可能被其他线程移除。甚至，在l_find过程中，其每一个元素都可能被移除。问题在于，任何时候拿到一个元素时，都不确定其是否还有效。元素的有效性包括其是否还在链表中，其指向的内存是否还有效。

解决方案

通过为元素指针增加一个有效性标志位，配合CAS操作的互斥性，就可以解决元素有效性判定问题。

因为node_t放在内存中是会对齐的，所以指向node_t的指针值低几位是不会用到的，从而可以在低几位里设置标志，这样在做CAS的时候，就实现了DCAS的效果，相当于将两个逻辑上的操作变成了一个原子操作。想象下引用计数对象的线程安全性，其内包装的指针是线程安全的，但对象本身不是。

CAS的互斥性，在若干个线程CAS相同的对象时，只有一个线程会成功，失败的线程就可以以此判定目标对象发生了变更。改进后的代码（代码仅做示例用，不保证正确）：

typedef size_t markable_t;
    // 最低位置1，表示元素被删除
    #define HAS_MARK(p) ((markable_t)p & 0x01)
    #define MARK(p) ((markable_t)p | 0x01)
    #define STRIP_MARK(p) ((markable_t)p & ~0x01)

    int l_insert(node_t *head, key_t key, value_t val) {
        node_t *pred, *item, *new_item;
        while (TRUE) {
            if (l_find(&pred, &item, head, key)) { 
                return FALSE;
            }
            new_item = (node_t*) malloc(sizeof(node_t));
            new_item->key = key;
            new_item->val = val;
            new_item->next = item;
            // A. 虽然find拿到了合法的pred，但是在以下代码之前pred可能被删除，此时pred->next被标记
            //    pred->next != item，该CAS会失败，失败后重试
            if (CAS(&pred->next, item, new_item)) {
                return TRUE;
            }
            free(new_item);
        }
        return FALSE;
    }

    int l_remove(node_t *head, key_t key) {
        node_t *pred, *item;
        while (TRUE) {
            if (!l_find(&pred, &item, head, key)) {
                return FALSE;
            }
            node_t *inext = item->next;
            // B. 删除item前先标记item->next，如果CAS失败，那么情况同insert一样，有其他线程在find之后
            //    删除了item，失败后重试
            if (!CAS(&item->next, inext, MARK(inext))) {
                continue;
            }
            // C. 对同一个元素item删除时，只会有一个线程成功走到这里
            if (CAS(&pred->next, item, STRIP_MARK(item->next))) {
                haz_defer_free(item);
                return TRUE;
            }
        }
        return FALSE;
    }

    int l_find(node_t **pred_ptr, node_t **item_ptr, node_t *head, key_t key) {
        node_t *pred = head;
        node_t *item = head->next;
        hazard_t *hp1 = haz_get(0);
        hazard_t *hp2 = haz_get(1);
        while (item) {
            haz_set_ptr(hp1, pred);
            haz_set_ptr(hp2, item);
            /* 
             如果已被标记，那么紧接着item可能被移除链表甚至释放，所以需要重头查找
            */
            if (HAS_MARK(item->next)) { 
                return l_find(pred_ptr, item_ptr, head, key);
            }
            int d = KEY_CMP(item->key, key);
            if (d >= 0) {
                *pred_ptr = pred;
                *item_ptr = item;
                return d == 0 ? TRUE : FALSE;
            }
            pred = item;
            item = item->next;
        } 
        *pred_ptr = pred;
        *item_ptr = NULL;
        return FALSE;
    }

haz_get、haz_set_ptr之类的函数是一个hazard pointer实现，用于支持多线程下内存的GC。上面的代码中，要删除一个元素item时，会标记item->next，从而使得insert时中那个CAS不需要做任何调整。总结下这里的线程竞争情况：

insert中find到正常的pred及item，pred->next == item，然后在CAS前有线程删除了pred，此时pred->next == MARK(item)，CAS失败，重试；删除分为2种情况：a) 从链表移除，得到标记，pred可继续访问；b) pred可能被释放内存，此时再使用pred会错误。为了处理情况b，所以引入了类似hazard pointer的机制，可以有效保障任意一个指针p只要还有线程在使用它，它的内存就不会被真正释放
insert中有多个线程在pred后插入元素，此时同样由insert中的CAS保证，这个不多说
remove中情况同insert，find拿到了有效的pred和next，但在CAS的时候pred被其他线程删除，此时情况同insert，CAS失败，重试
任何时候改变链表结构时，无论是remove还是insert，都需要重试该操作
find中遍历时，可能会遇到被标记删除的item，此时item根据remove的实现很可能被删除，所以需要重头开始遍历

ABA问题

ABA问题还是存在的，insert中：

if (CAS(&pred->next, item, new_item)) {
        return TRUE;
    }

如果CAS之前，pred后的item被移除，又以相同的地址值加进来，但其value变了，此时CAS会成功，但链表可能就不是有序的了。pred->val < new_item->val > item->val

为了解决这个问题，可以利用指针值地址对齐的其他位来存储一个计数，用于表示pred->next的改变次数。当insert拿到pred时，pred->next中存储的计数假设是0，CAS之前其他线程移除了pred->next又新增回了item，此时pred->next中的计数增加，从而导致insert中CAS失败。

// 最低位留作删除标志
    #define MASK ((sizeof(node_t) - 1) & ~0x01)

    #define GET_TAG(p) ((markable_t)p & MASK)
    #define TAG(p, tag) ((markable_t)p | (tag))
    #define MARK(p) ((markable_t)p | 0x01)
    #define HAS_MARK(p) ((markable_t)p & 0x01)
    #define STRIP_MARK(p) ((node_t*)((markable_t)p & ~(MASK | 0x01)))

remove的实现：

/* 先标记再删除 */
    if (!CAS(&sitem->next, inext, MARK(inext))) {
        continue;
    }
    int tag = GET_TAG(pred->next) + 1;
    if (CAS(&pred->next, item, TAG(STRIP_MARK(sitem->next), tag))) {
        haz_defer_free(sitem);
        return TRUE;
    }

insert中也可以更新pred->next的计数。

总结

无锁的实现，本质上都会依赖于CAS的互斥性。从头实现一个lock free的数据结构，可以深刻感受到lock free实现的tricky。最终代码可以从这里github获取。代码中为了简单，实现了一个不是很强大的hazard pointer，可以参考之前的博文。

Kevin Lynx 2015-05-05 19:47 发表评论

并行编程中的内存回收Hazard Pointer

Kevin Lynx — Sun, 03 May 2015 12:46:00 GMT

接上篇使用RCU技术实现读写线程无锁，在没有GC机制的语言中，要实现Lock free的算法，就免不了要自己处理内存回收的问题。

Hazard Pointer是另一种处理这个问题的算法，而且相比起来不但简单，功能也很强大。锁无关的数据结构与Hazard指针中讲得很好，Wikipedia Hazard pointer也描述得比较清楚，所以我这里就不讲那么细了。

一个简单的实现可以参考我的github haz_ptr.c

原理

基本原理无非也是读线程对指针进行标识，指针(指向的内存)要释放时都会缓存起来延迟到确认没有读线程了才对其真正释放。

中的描述：

Each reader thread owns a single-writer/multi-reader shared pointer called “hazard pointer.” When a reader thread assigns the address of a map to its hazard pointer, it is basically announcing to other threads (writers), “I am reading this map. You can replace it if you want, but don’t change its contents and certainly keep your deleteing hands off it.”

关键的结构包括：Hazard pointer、Thread Free list

Hazard pointer：一个读线程要使用一个指针时，就会创建一个Hazard pointer包装这个指针。一个Hazard pointer会被一个线程写，多个线程读。

struct HazardPointer {
        void *real_ptr; // 包装的指针
        ... // 不同的实现有不同的成员
    };

    void func() {
        HazardPointer *hp = accquire(_real_ptr);
        ... // use _real_ptr
        release(hp);
    }

Thread Free List：每个线程都有一个这样的列表，保存着将要释放的指针列表，这个列表仅对应的线程读写

void defer_free(void *ptr) {
        _free_list.push_back(ptr);
    }

当某个线程要尝试释放Free List中的指针时，例如指针ptr，就检查所有其他线程使用的Hazard pointer，检查是否存在包装了ptr的Hazard pointer，如果没有则说明没有读线程正在使用ptr，可以安全释放ptr。

void gc() {
        for(ptr in _free_list) {
            conflict = false
            for (hp in _all_hazard_pointers) {
                if (hp->_real_ptr == ptr) {
                    confilict = true
                    break
                }
            }
            if (!conflict)
                delete ptr
        }
    }

以上，其实就是Hazard Pointer的主要内容。

Hazard Pointer的管理

上面的代码中没有提到_all_hazard_pointers及accquire的具体实现，这就是Hazard Pointer的管理问题。

《锁无关的数据结构与Hazard指针》文中创建了一个Lock free的链表来表示这个全局的Hazard Pointer List。每个Hazard Pointer有一个成员标识其是否可用。这个List中也就保存了已经被使用的Hazard Pointer集合和未被使用的Hazard Pointer集合，当所有Hazard Pointer都被使用时，就会新分配一个加进这个List。当读线程不使用指针时，需要归还Hazard Pointer，直接设置可用成员标识即可。要gc()时，就直接遍历这个List。

要实现一个Lock free的链表，并且仅需要实现头插入，还是非常简单的。本身Hazard Pointer标识某个指针时，都是用了后立即标识，所以这个实现直接支持了动态线程，支持线程的挂起等。

在nbds项目中也有一个Hazard Pointer的实现，相对要弱一点。它为每个线程都设置了自己的Hazard Pointer池，写线程要释放指针时，就访问所有其他线程的Hazard Pointer池。

typedef struct haz_local {
        // Free List
        pending_t *pending; // to be freed
        int pending_size;
        int pending_count;

        // Hazard Pointer 池，动态和静态两种
        haz_t static_haz[STATIC_HAZ_PER_THREAD];

        haz_t **dynamic;
        int dynamic_size;
        int dynamic_count;

    } __attribute__ ((aligned(CACHE_LINE_SIZE))) haz_local_t;

    static haz_local_t haz_local_[MAX_NUM_THREADS] = {};

每个线程当然就涉及到haz_local_索引(ID)的分配，就像使用RCU技术实现读写线程无锁中的一样。这个实现为了支持线程动态创建，就需要一套线程ID的重用机制，相对复杂多了。

附录

最后，附上一些并行编程中的一些概念。

Lock Free & Wait Free

常常看到Lock Free和Wait Free的概念，这些概念用于衡量一个系统或者说一段代码的并行级别，并行级别可参考并行编程——并发级别。总之Wait Free是一个比Lock Free更牛逼的级别。

我自己的理解，例如《锁无关的数据结构与Hazard指针》中实现的Hazard Pointer链表就可以说是Lock Free的，注意它在插入新元素到链表头时，因为使用CAS，总免不了一个busy loop，有这个特征的情况下就算是Lock Free，虽然没锁，但某个线程的执行情况也受其他线程的影响。

相对而言，Wait Free则是每个线程的执行都是独立的，例如《锁无关的数据结构与Hazard指针》中的Scan函数。“每个线程的执行时间都不依赖于其它任何线程的行为”

锁无关(Lock-Free)意味着系统中总存在某个线程能够得以继续执行；而等待无关(Wait-Free)则是一个更强的条件，它意味着所有线程都能往下进行。

ABA问题

在实现Lock Free算法的过程中，总是要使用CAS原语的，而CAS就会带来ABA问题。

在进行CAS操作的时候，因为在更改V之前，CAS主要询问“V的值是否仍然为A”，所以在第一次读取V之后以及对V执行CAS操作之前，如果将值从A改为B，然后再改回A，会使基于CAS的算法混乱。在这种情况下，CAS操作会成功。这类问题称为ABA问题。

Wiki Hazard Pointer提到了一个ABA问题的好例子：在一个Lock free的栈实现中，现在要出栈，栈里的元素是[A, B, C]，head指向栈顶，那么就有compare_and_swap(target=&head, newvalue=B, expected=A)。但是在这个操作中，其他线程把A B都出栈，且删除了B，又把A压入栈中，即[A, C]。那么前一个线程的compare_and_swap能够成功，此时head指向了一个已经被删除的B。stackoverflow上也有个例子 Real-world examples for ABA in multithreading

对于CAS产生的这个ABA问题，通常的解决方案是采用CAS的一个变种DCAS。DCAS，是对于每一个V增加一个引用的表示修改次数的标记符。对于每个V，如果引用修改了一次，这个计数器就加1。然后再这个变量需要update的时候，就同时检查变量的值和计数器的值。

但也早有人提出DCAS也不是ABA problem 的银弹。

Kevin Lynx 2015-05-03 20:46 发表评论

使用RCU技术实现读写线程无锁

Kevin Lynx — Sun, 19 Apr 2015 11:10:00 GMT

在一个系统中有一个写线程和若干个读线程，读写线程通过一个指针共用了一个数据结构，写线程改写这个结构，读线程读取该结构。在写线程改写这个数据结构的过程中，加锁情况下读线程由于等待锁耗时会增加。

可以利用RCU (Read Copy Update What is rcu)的思想来去除这个锁。本文提到的主要实现代码：gist

RCU

RCU可以说是一种替代读写锁的方法。其基于一个事实：当写线程在改变一个指针时，读线程获取这个指针，要么获取到老的值，要么获取到新的值。RCU的基本思想其实很简单，参考What is RCU中Toy implementation可以很容易理解。一种简单的RCU流程可以描述为：

写线程：

old_ptr = _ptr
tmp_ptr = copy(_ptr)     // copy
change(tmp_ptr)          // change 
_ptr = tmp_ptr           // update
synchroize(tmp_ptr)

写线程要更新_ptr指向的内容时，先复制一份新的，基于新的进行改变，更新_ptr指针，最后同步释放老的内存。

读线程：

tmp_ptr = _ptr
use(tmp_ptr)
dereference(tmp_ptr)

读线程直接使用_ptr，使用完后需要告诉写线程自己不再使用_ptr。读线程获取_ptr时，可能会获取到老的也可能获取到新的，无论哪种RCU都需要保证这块内存是有效的。重点在synchroize和dereference。synchroize会等待所有使用老的_ptr的线程dereference，对于新的_ptr使用者其不需要等待。这个问题说白了就是写线程如何知道old_ptr没有任何读线程在使用，可以安全地释放。

这个问题实际上在wait-free的各种实现中有好些解法，how-when-to-release-memory-in-wait-free-algorithms这里有人总结了几种方法，例如Hazard pointers、Quiescence period based reclamation。

简单地使用引用计数智能指针是无法解决这个问题的，因为智能指针自己不是线程安全的，例如：

tmp_ptr = _ptr      // 1
tmp_ptr->addRef()   // 2
use
tmp_ptr->release()

代码1/2行不是原子的，所以当取得tmp_ptr准备addRef时，tmp_ptr可能刚好被释放了。

Quiescence period based reclamation方法指的是读线程需要声明自己处于Quiescence period，也就是不使用_ptr的时候，当其使用_ptr的时候实际是进入了一个逻辑上的临界区，当所有读线程都不再使用_ptr的时候，写线程就可以对内存进行安全地释放。

本文正是描述了一种Quiescence period based reclamation实现。这个实现可以用于有一个写线程和多个读线程共用若干个数据的场景。

实现

该方法本质上把数据同步分解为基本的内存单元读写。使用方式上可描述为：

读线程：

tmp_ptr = _ptr
use
update() // 标识自己不再使用任何共享数据

写线程：

old_ptr = _ptr
tmp_ptr = copy(_ptr)
change(tmp_ptr)
_ptr = tmp_ptr
gc()
defer_free(old_ptr)

以下具体描述读写线程的实现。

写线程

写线程负责标识内存需要被释放，以及检查何时可以真正释放内存。其维护了一个释放内存队列：

void *_pending[8]
    uint64_t _head, _tail

    void defer_free(void *p) {
        _head ++
        _pending[PENDING_POS(_head)] = p
    }

    gc() {
        for (_tail -> find_free_pos())
            free(_pending[_tail])
    }

find_free_pos找到一个可释放内存位置，在[_tail, find_free_pos())这个区间内所有内存是可以安全被释放的。

队列位置_head/_tail一直增大，PENDING_POS就是对这个位置取模，限定在队列大小范围内也是可行的，无论哪种方式，_head从逻辑上说一直>=_tail，但在实际中可能小于_tail，所以实现时不使用大小判定，而是：

gc() {
        pos = find_free_pos()
        while (_tail != pos) {
            free(_pending[PENDING_POS(_tail)])
            _tail ++
        }
    }

读线程

读线程不再使用共享内存时，就标识自己：

update() {
        static __thread int tid
        _tmark[tid] = _head
    }

读线程的状态会影响写线程的回收逻辑，其状态分为：

初始
活跃，会调用到update
暂停，其他地方同步，或被挂起
退出

读线程处于活跃状态时，它会不断地更新自己可释放内存位置(_tmark[tid])。写线程检查所有读线程的_tmark[tid]，[_tail, min(_tmark[]))是所有读线程都不再使用的内存区间，可以被安全释放。

find_free_pos() {
        min = MAX_INTEGER
        pos = 0
        for (tid = 0; tid < max_threads; ++tid) {
            tpos = _tmark[tid]
            offset = tpos - tail
            if (offset < min) {
                min = offset
                pos = tpos
            }
        }
        return pos
    }

当读线程暂停时，其_tmark[tid]可能会在很长一段时间里得不到更新，此时会阻碍写线程释放内存。所以需要方法来标识读线程是否进入暂停状态。通过设置一个上次释放内存位置_tfreeds[tid]，标识每个线程当前内存释放到的位置。如果一个线程处于暂停状态了，那么在一定时间后，_tfreeds[tid] == _tmark[tid]。在查找可释放位置时，就需要忽略暂停状态的读线程：

find_free_pos() {
        min = MAX_INTEGER
        pos = _head
        for (tid = 0; tid < max_threads; ++tid) {
            tpos = _tmark[tid]
            if (tpos == _tfreeds[tid]) continue
            offset = tpos - tail
            if (offset < min) {
                min = offset
                pos = tpos
            }
        }
        for (tid = 0; tid < max_threads; ++tid) {
            if (_tfreeds[tid] != _tmark[tid]) 
                _tfreeds[tid] = pos
        }
        return pos
    }

但是当所有线程都处于暂停状态时，写线程可能还在工作，上面的实现就会返回_head，此时写线程依然可以正常释放内存。

小结，该方法原理可用下图表示：

线程动态增加/减少

如果读线程可能中途退出，中途动态增加，那么_tmark[]就需要被复用，此时线程tid的分配调整为动态的即可：

class ThreadIdPool {
    public:
        // 动态获取一个线程tid，某线程每次调用该接口返回相同的值
        int get()
        // 线程退出时回收该tid
        void put(int id)
    }

ThreadIdPool的实现无非就是利用TLS，以及在线程退出时得到通知以回收tid。那么对于读线程的update实现变为：

update() {
        tid = _idPool->get()
        _tmark[tid] = _head
    }

当某个线程退出时，_tmark[tid]和_tfreeds[tid]不需要做任何处理，当新创建的线程复用了该tid时，可以立即复用_tmark[tid]和_tfreeds[tid]，此时这2个值必然是相等的。

以上，就是整个方法的实现。

线程可读可写

以上方法适用场景还是不够通用。在nbds项目（实现了一些无锁数据结构的toy project）中有一份虽然简单但也有启发的实现(rcu.c)。该实现支持任意线程defer_free，所有线程update。update除了声明不再使用任何共享内存外，还可能回收内存。任意线程都可能维护一些待释放的内存，任意一块内存可能被任意其他线程使用。那么它是如何内存回收的？

本文描述的方法是所有读线程自己声明自己，然后由写线程主动来检查。不同于此方法， nbds的实现，基于一种通知扩散的方式。该方式以这样一种方式工作：

当某个线程尝试内存回收时，它需要知道所有其他线程的空闲位置（相当于_tmark[tid]），它通知下一个线程我需要释放的范围。当下一个线程update时（离开临界区），它会将上个线程的通知继续告诉下一个线程，直到最后这个通知回到发起线程。那么对于发起线程而言，这个释放请求在所有线程中走了一遍，得到了大家的认可，可以安全释放。每个线程都以这样的方式工作。

void rcu_defer_free (void *x) {
        ...
        rcu_[next_thread_id][tid_] = rcu_last_posted_[tid_][tid_] = pending_[tid_]->head;
        ...
    }

    void rcu_update (void) {
        ...
        for (i = 0; i < num_threads_; ++i) {
            ...     
            uint64_t x = rcu_[tid_][i]; // 其它线程发给自己的通知
            rcu_[next_thread_id][i] = rcu_last_posted_[tid_][i] = x; // 扩散出去
            ...
        }
        ...
        while (q->tail != rcu_[tid_][tid_]) {
            free
        }     
        ...
    }

这个实现相对简单，不支持线程暂停，以及线程动态增加和减少。

Kevin Lynx 2015-04-19 19:10 发表评论

记一次tcmalloc分配内存引起的coredump

Kevin Lynx — Mon, 06 Apr 2015 10:33:00 GMT

现象

线上的服务出现coredump，堆栈为：

#0  0x000000000045d145 in GetStackTrace(void**, int, int) ()
#1  0x000000000045ec22 in tcmalloc::PageHeap::GrowHeap(unsigned long) ()
#2  0x000000000045eeb3 in tcmalloc::PageHeap::New(unsigned long) ()
#3  0x0000000000459ee8 in tcmalloc::CentralFreeList::Populate() ()
#4  0x000000000045a088 in tcmalloc::CentralFreeList::FetchFromSpansSafe() ()
#5  0x000000000045a10a in tcmalloc::CentralFreeList::RemoveRange(void**, void**, int) ()
#6  0x000000000045c282 in tcmalloc::ThreadCache::FetchFromCentralCache(unsigned long, unsigned long) ()
#7  0x0000000000470766 in tc_malloc ()
#8  0x00007f75532cd4c2 in __conhash_get_rbnode (node=0x22c86870, hash=30)
        at build/release64/cm_sub/conhash/conhash_inter.c:88
#9  0x00007f75532cd76e in __conhash_add_replicas (conhash=0x24fbc7e0, iden=)
        at build/release64/cm_sub/conhash/conhash_inter.c:45
#10 0x00007f75532cd1fa in conhash_add_node (conhash=0x24fbc7e0, iden=0) at build/release64/cm_sub/conhash/conhash.c:72
#11 0x00007f75532c651b in cm_sub::TopoCluster::initLBPolicyInfo (this=0x2593a400)
        at build/release64/cm_sub/topo_cluster.cpp:114
#12 0x00007f75532cad73 in cm_sub::TopoClusterManager::processClusterMapTable (this=0xa219e0, ref=0x267ea8c0)
        at build/release64/cm_sub/topo_cluster_manager.cpp:396
#13 0x00007f75532c5a93 in cm_sub::SubRespMsgProcess::reinitCluster (this=0x9c2f00, msg=0x4e738ed0)
        at build/release64/cm_sub/sub_resp_msg_process.cpp:157
...

查看了应用层相关数据结构，基本数据都是没有问题的。所以最初怀疑是tcmalloc内部维护了错误的内存，在分配内存时出错，这个堆栈只是问题的表象。几天后，线上的另一个服务，基于同样的库，也core了，堆栈还是一样的。

最初定位问题都是从最近更新的东西入手，包括依赖的server环境，但都没有明显的问题，所以最后只能从core的直接原因入手。

分析GetStackTrace

确认core的详细位置：

# core在该指令
0x000000000045d145 <_Z13GetStackTracePPvii+21>: mov    0x8(%rax),%r9

(gdb) p/x $rip              # core 的指令位置
$9 = 0x45d145
(gdb) p/x $rax              
$10 = 0x4e73aa58
(gdb) x/1a $rax+0x8         # rax + 8 = 0x4e73aa60
0x4e73aa60:     0x0

该指令尝试从[0x4e73aa60]处读取内容，然后出错，这个内存单元不可读。但是具体这个指令在代码中是什么意思，需要将这个指令对应到代码中。获取tcmalloc的源码，发现GetStackTrace根据编译选项有很多实现，所以这里选择最可能的实现，然后对比汇编以确认代码是否匹配。最初选择的是stacktrace_x86-64-inl.h，后来发现完全不匹配，又选择了stacktrace_x86-inl.h。这个实现版本里也有对64位平台的支持。

stacktrace_x86-inl.h里使用了一些宏来生成函数名和参数，精简后代码大概为：

int GET_STACK_TRACE_OR_FRAMES {
      void **sp;
      unsigned long rbp;
      __asm__ volatile ("mov %%rbp, %0" : "=r" (rbp));
      sp = (void **) rbp;

      int n = 0;
      while (sp && n < max_depth) {
        if (*(sp+1) == reinterpret_cast<void *>(0)) {
          break;
        }
        void **next_sp = NextStackFrameIS_STACK_FRAMES, IS_WITH_CONTEXT>(sp, ucp);
        if (skip_count > 0) {
          skip_count--;
        } else {
          result[n] = *(sp+1);
          n++;
        }
        sp = next_sp;
      }
      return n;
    }

NextStackFrame是一个模板函数，包含一大堆代码，精简后非常简单：

template<bool STRICT_UNWINDING, bool WITH_CONTEXT>
    static void **NextStackFrame(void **old_sp, const void *uc) {
      void **new_sp = (void **) *old_sp;
      if (STRICT_UNWINDING) {
        if (new_sp <= old_sp) return NULL;
        if ((uintptr_t)new_sp - (uintptr_t)old_sp > 100000) return NULL;
      } else {
        if (new_sp == old_sp) return NULL;
        if ((new_sp > old_sp)
            && ((uintptr_t)new_sp - (uintptr_t)old_sp > 1000000)) return NULL;
      }
      if ((uintptr_t)new_sp & (sizeof(void *) - 1)) return NULL;

      return new_sp;
    }

上面这个代码到汇编的对比过程还是花了些时间，其中汇编中出现的一些常量可以大大缩短对比时间，例如上面出现了100000，汇编中就有：

0x000000000045d176 <_Z13GetStackTracePPvii+70>: cmp    $0x186a0,%rbx  # 100000=0x186a0

注意NextStackFrame中的 if (STRICT_UNWINDING)使用的是模板参数，这导致生成的代码中根本没有else部分，也就没有1000000这个常量

在对比代码的过程中，可以知道关键的几个寄存器、内存位置对应到代码中的变量，从而可以还原core时的现场环境。分析过程中不一定要从第一行汇编读，可以从较明显的位置读，从而还原整个代码，函数返回指令、跳转指令、比较指令、读内存指令、参数寄存器等都是比较明显对应的地方。

另外注意GetStackTrace在RecordGrowth中调用，传入了3个参数：

GetStackTrace(t->stack, kMaxStackDepth-1, 3); // kMaxStackDepth = 31

以下是我分析的简单注解：

(gdb) disassemble
Dump of assembler code for function _Z13GetStackTracePPvii:
0x000000000045d130 <_Z13GetStackTracePPvii+0>:  push   %rbp
0x000000000045d131 <_Z13GetStackTracePPvii+1>:  mov    %rsp,%rbp
0x000000000045d134 <_Z13GetStackTracePPvii+4>:  push   %rbx
0x000000000045d135 <_Z13GetStackTracePPvii+5>:  mov    %rbp,%rax
0x000000000045d138 <_Z13GetStackTracePPvii+8>:  xor    %r8d,%r8d
0x000000000045d13b <_Z13GetStackTracePPvii+11>: test   %rax,%rax
0x000000000045d13e <_Z13GetStackTracePPvii+14>: je     0x45d167 <_Z13GetStackTracePPvii+55>
0x000000000045d140 <_Z13GetStackTracePPvii+16>: cmp    %esi,%r8d        # while ( .. max_depth > n ?
0x000000000045d143 <_Z13GetStackTracePPvii+19>: jge    0x45d167 <_Z13GetStackTracePPvii+55>
0x000000000045d145 <_Z13GetStackTracePPvii+21>: mov    0x8(%rax),%r9    # 关键位置：*(sp+1) -> r9, rax 对应 sp变量
0x000000000045d149 <_Z13GetStackTracePPvii+25>: test   %r9,%r9          # *(sp+1) == 0 ?
0x000000000045d14c <_Z13GetStackTracePPvii+28>: je     0x45d167 <_Z13GetStackTracePPvii+55>
0x000000000045d14e <_Z13GetStackTracePPvii+30>: mov    (%rax),%rcx      # new_sp = *old_sp，这里已经是NextStackFrame的代码
0x000000000045d151 <_Z13GetStackTracePPvii+33>: cmp    %rcx,%rax        # new_sp <= old_sp ? 
0x000000000045d154 <_Z13GetStackTracePPvii+36>: jb     0x45d170 <_Z13GetStackTracePPvii+64>  # new_sp > old_sp 跳转
0x000000000045d156 <_Z13GetStackTracePPvii+38>: xor    %ecx,%ecx
0x000000000045d158 <_Z13GetStackTracePPvii+40>: test   %edx,%edx        # skip_count > 0 ?
0x000000000045d15a <_Z13GetStackTracePPvii+42>: jle    0x45d186 <_Z13GetStackTracePPvii+86>
0x000000000045d15c <_Z13GetStackTracePPvii+44>: sub    $0x1,%edx        # skip_count--
0x000000000045d15f <_Z13GetStackTracePPvii+47>: mov    %rcx,%rax        
0x000000000045d162 <_Z13GetStackTracePPvii+50>: test   %rax,%rax        # while (sp ?
0x000000000045d165 <_Z13GetStackTracePPvii+53>: jne    0x45d140 <_Z13GetStackTracePPvii+16>
0x000000000045d167 <_Z13GetStackTracePPvii+55>: pop    %rbx
0x000000000045d168 <_Z13GetStackTracePPvii+56>: leaveq 
0x000000000045d169 <_Z13GetStackTracePPvii+57>: mov    %r8d,%eax        # r8 存储了返回值，r8=n
0x000000000045d16c <_Z13GetStackTracePPvii+60>: retq                    # return n
0x000000000045d16d <_Z13GetStackTracePPvii+61>: nopl   (%rax)
0x000000000045d170 <_Z13GetStackTracePPvii+64>: mov    %rcx,%rbx        
0x000000000045d173 <_Z13GetStackTracePPvii+67>: sub    %rax,%rbx        # offset = new_sp - old_sp
0x000000000045d176 <_Z13GetStackTracePPvii+70>: cmp    $0x186a0,%rbx    # offset > 100000 ?
0x000000000045d17d <_Z13GetStackTracePPvii+77>: ja     0x45d156 <_Z13GetStackTracePPvii+38> # return NULL
0x000000000045d17f <_Z13GetStackTracePPvii+79>: test   $0x7,%cl         # new_sp & (sizeof(void*) - 1)
0x000000000045d182 <_Z13GetStackTracePPvii+82>: je     0x45d158 <_Z13GetStackTracePPvii+40>
0x000000000045d184 <_Z13GetStackTracePPvii+84>: jmp    0x45d156 <_Z13GetStackTracePPvii+38>
0x000000000045d186 <_Z13GetStackTracePPvii+86>: movslq %r8d,%rax        # rax = n
0x000000000045d189 <_Z13GetStackTracePPvii+89>: add    $0x1,%r8d        # n++
0x000000000045d18d <_Z13GetStackTracePPvii+93>: mov    %r9,(%rdi,%rax,8)# 关键位置：result[n] = *(sp+1)
0x000000000045d191 <_Z13GetStackTracePPvii+97>: jmp    0x45d15f <_Z13GetStackTracePPvii+47>

分析过程比较耗时，同时还可以分析下GetStackTrace函数的实现原理，其实就是利用RBP寄存器不断回溯，从而得到整个调用堆栈各个函数的地址（严格来说是返回地址）。简单示意下函数调用中RBP的情况：

   ...
saved registers          # i.e push rbx
local variabes           # i.e sub 0x10, rsp
return address           # call xxx
last func RBP            # push rbp; mov rsp, rbp
saved registers
local variables 
return address
last func RBP
...                      # rsp

总之，一般情况下，任何一个函数中，RBP寄存器指向了当前函数的栈基址，该栈基址中又存储了调用者的栈基址，同时该栈基址前面还存储了调用者的返回地址。所以，GetStackTrace的实现，简单来说大概就是：

sp = rbp  // 取得当前函数GetStackTrace的栈基址
    while (n < max_depth) {
        new_sp = *sp
        result[n] = *(new_sp+1)
        n++
    }

以上，最终就知道了以下关键信息：

r8 对应变量 n，表示当前取到第几个栈帧了
rax 对应变量 sp，代码core在 *(sp+1)
rdi 对应变量 result，用于存储取得的各个地址

然后可以看看现场是怎样的：

(gdb) x/10a $rdi
0x1ffc9b98:     0x45a088 <_ZN8tcmalloc15CentralFreeList18FetchFromSpansSafeEv+40>       0x45a10a <_ZN8tcmalloc15CentralFreeList11RemoveRangeEPPvS2_i+106>
0x1ffc9ba8:     0x45c282 <_ZN8tcmalloc11ThreadCache21FetchFromCentralCacheEmm+114>      0x470766 
0x1ffc9bb8:     0x7f75532cd4c2 <__conhash_get_rbnode+34>        0x0
0x1ffc9bc8:     0x0     0x0
0x1ffc9bd8:     0x0     0x0

(gdb) p/x $r8
$3 = 0x5

(gdb) p/x $rax
$4 = 0x4e73aa58

小结：

GetStackTrace在取调用__conhash_get_rbnode的函数时出错，取得了5个函数地址。当前使用的RBP为0x4e73aa58。

错误的RBP

RBP也是从堆栈中取出来的，既然这个地址有问题，首先想到的就是有代码局部变量/数组写越界。例如sprintf的使用。而且，一般写越界破坏堆栈，都可能是把调用者的堆栈破坏了，例如：

char s[32];
memcpy(s, p, 1024);

因为写入都是从低地址往高地址写，而调用者的堆栈在高地址。当然，也会遇到写坏调用者的调用者的堆栈，也就是跨栈帧越界写，例如以前遇到的：

len = vsnprintf(buf, sizeof(buf), fmt, wtf-long-string);
buf[len] = 0;

__conhash_get_rbnode的RBP是在tcmalloc的堆栈中取的：

(gdb) f 7
#7  0x0000000000470766 in tc_malloc ()
(gdb) x/10a $rsp
0x4e738b80:     0x4e73aa58      0x22c86870
0x4e738b90:     0x4e738bd0      0x85
0x4e738ba0:     0x4e73aa58      0x7f75532cd4c2 <__conhash_get_rbnode+34>   # 0x4e73aa58

所以这里就会怀疑是tcmalloc这个函数里有把堆栈破坏，这个时候就是读代码，看看有没有疑似危险的地方，未果。这里就陷入了僵局，怀疑又遇到了跨栈帧破坏的情况，这个时候就只能__conhash_get_rbnode调用栈中周围的函数翻翻，例如调用__conhash_get_rbnode的函数__conhash_add_replicas中恰好有字符串操作：

void __conhash_add_replicas(conhash_t *conhash, int32_t iden)
    {
        node_t* node = __conhash_create_node(iden, conhash->replica);
        ...
        char buf[buf_len]; // buf_len = 64
        ...
        snprintf(buf, buf_len, VIRT_NODE_HASH_FMT, node->iden, i);
        uint32_t hash = conhash->cb_hashfunc(buf);
        if(util_rbtree_search(&(conhash->vnode_tree), hash) == NULL)
        {
            util_rbtree_node_t* rbnode = __conhash_get_rbnode(node, hash);
            ...

这段代码最终发现是没有问题的，这里又耗费了不少时间。后来发现若干个函数里的RBP都有点奇怪，这个调用栈比较正常的范围是：0x4e738c90

(gdb) f 8
#8  0x00007f75532cd4c2 in __conhash_get_rbnode (node=0x22c86870, hash=30)
(gdb) p/x $rbp
$6 = 0x4e73aa58     # 这个还不算特别可疑
(gdb) f 9
#9  0x00007f75532cd76e in __conhash_add_replicas (conhash=0x24fbc7e0, iden=)
(gdb) p/x $rbp
$7 = 0x4e738c60     # 这个也不算特别可疑
(gdb) f 10
#10 0x00007f75532cd1fa in conhash_add_node (conhash=0x24fbc7e0, iden=0) at build/release64/cm_sub/conhash/conhash.c:72
(gdb) p/x $rbp      # 可疑
$8 = 0x0
(gdb) f 11
#11 0x00007f75532c651b in cm_sub::TopoCluster::initLBPolicyInfo (this=0x2593a400)
(gdb) p/x $rbp      # 可疑
$9 = 0x2598fef0

为什么很多函数中RBP都看起来不正常？ 想了想真要是代码里把堆栈破坏了，这错误得发生得多巧妙？

错误RBP的来源

然后转机来了，脑海中突然闪出-fomit-frame-pointer。编译器生成的代码中是可以不需要栈基址指针的，也就是RBP寄存器不作为栈基址寄存器。大部分函数或者说开启了frame-pointer的函数，其函数头都会有以下指令：

push   %rbp
mov    %rsp,%rbp
...

表示保存调用者的栈基址到栈中，以及设置自己的栈基址。看下__conhash系列函数；

Dump of assembler code for function __conhash_get_rbnode:
0x00007f75532cd4a0 <__conhash_get_rbnode+0>:    mov    %rbx,-0x18(%rsp)
0x00007f75532cd4a5 <__conhash_get_rbnode+5>:    mov    %rbp,-0x10(%rsp)
...

这个库是单独编译的，没有显示指定-fno-omit-frame-pointer，查阅gcc手册，o2优化是开启了omit-frame-pinter 的。

在没有RBP的情况下，tcmalloc的GetStackTrace尝试读RBP取获取调用返回地址，自然是有问题的。但是，如果整个调用栈中的函数，要么有RBP，要么没有RBP，那么GetStackTrace取出的结果最多就是跳过一些栈帧，不会出错。 除非，这中间的某个函数把RBP寄存器另作他用（编译器省出这个寄存器肯定是要另作他用的）。所以这里继续追查这个错误地址0x4e73aa58的来源。

来源已经比较明显，肯定是__conhash_get_rbnode中设置的，因为这个函数的RBP是在被调用者tcmalloc中保存的。

Dump of assembler code for function __conhash_get_rbnode:
0x00007f75532cd4a0 <__conhash_get_rbnode+0>:    mov    %rbx,-0x18(%rsp)
0x00007f75532cd4a5 <__conhash_get_rbnode+5>:    mov    %rbp,-0x10(%rsp)
0x00007f75532cd4aa <__conhash_get_rbnode+10>:   mov    %esi,%ebp                    # 改写了RBP
0x00007f75532cd4ac <__conhash_get_rbnode+12>:   mov    %r12,-0x8(%rsp)
0x00007f75532cd4b1 <__conhash_get_rbnode+17>:   sub    $0x18,%rsp
0x00007f75532cd4b5 <__conhash_get_rbnode+21>:   mov    %rdi,%r12
0x00007f75532cd4b8 <__conhash_get_rbnode+24>:   mov    $0x30,%edi
0x00007f75532cd4bd <__conhash_get_rbnode+29>:   callq  0x7f75532b98c8   # 调用tcmalloc，汇编到这里即可

这里打印RSI寄存器的值可能会被误导，因为任何时候打印寄存器的值可能都是错的，除非它有被显示保存。不过这里可以看出RSI的值来源于参数(RSI对应第二个参数)：

void __conhash_add_replicas(conhash_t *conhash, int32_t iden)
    {
        node_t* node = __conhash_create_node(iden, conhash->replica);
        ...
        char buf[buf_len]; // buf_len = 64
        ...
        snprintf(buf, buf_len, VIRT_NODE_HASH_FMT, node->iden, i);
        uint32_t hash = conhash->cb_hashfunc(buf); // hash值由一个字符串哈希函数计算
        if(util_rbtree_search(&(conhash->vnode_tree), hash) == NULL)
        {
            util_rbtree_node_t* rbnode = __conhash_get_rbnode(node, hash);  // hash值
            ...

追到__conhash_add_replicas：

0x00007f75532cd764 <__conhash_add_replicas+164>:        mov    %ebx,%esi    # 来源于rbx
0x00007f75532cd766 <__conhash_add_replicas+166>:        mov    %r15,%rdi
0x00007f75532cd769 <__conhash_add_replicas+169>:        callq  0x7f75532b9e48 <__conhash_get_rbnode@plt>

(gdb) p/x $rbx
$11 = 0x4e73aa58
(gdb) p/x hash
$12 = 0x4e73aa58      # 0x4e73aa58

找到了0x4e73aa58的来源。这个地址值竟然是一个字符串哈希算法算出来的！这里还可以看看这个字符串的内容：

(gdb) x/1s $rsp
0x4e738bd0:      "conhash-00000-00133"

这个碉堡的哈希函数是conhash_hash_def。

coredump的条件

以上，既然只要某个库omit-frame-pointer，那tcmalloc就可能出错，为什么发生的频率并不高呢？这个可以回到GetStackTrace尤其是NextStackFrame的实现，其中包含了几个合法RBP的判定：

if (new_sp <= old_sp) return NULL;  // 上一个栈帧的RBP肯定比当前的大
        if ((uintptr_t)new_sp - (uintptr_t)old_sp > 100000) return NULL; // 指针值范围还必须在100000内
        ...
    if ((uintptr_t)new_sp & (sizeof(void *) - 1)) return NULL; // 由于本身保存的是指针，所以还必须是sizeof(void*)的整数倍，对齐

有了以上条件，才使得这个core几率变得很低。

总结

最后，如果你很熟悉tcmalloc，整个问题估计就被秒解了：tcmalloc INSTALL

附

另外附上另一个有意思的东西。

在分析__conhash_add_replicas时，其内定义了一个64字节的字符数组，查看其堆栈：

(gdb) x/20a $rsp
0x4e738bd0:     0x2d687361686e6f63      0x30302d3030303030          # 这些是字符串conhash-00000-00133
0x4e738be0:     0x333331        0x0
0x4e738bf0:     0x0     0x7f75532cd69e <__conhash_create_node+78>
0x4e738c00:     0x24fbc7e0      0x4e738c60
0x4e738c10:     0x24fbc7e0      0x7f75532cd6e3 <__conhash_add_replicas+35>
0x4e738c20:     0x0     0x24fbc7e8
0x4e738c30:     0x4e738c20      0x24fbc7e0
0x4e738c40:     0x22324360      0x246632c0
0x4e738c50:     0x0     0x0
0x4e738c60:     0x0     0x7f75532cd1fa

最开始我觉得buf占64字节，也就是整个[0x4e738bd0, 0x4e738c10)内存，但是这块内存里居然有函数地址，这一度使我怀疑这里有问题。后来醒悟这些地址是定义buf前调用__conhash_create_node产生的，调用过程中写到堆栈里，调用完后栈指针改变，但并不需要清空栈中的内容。

Kevin Lynx 2015-04-06 18:33 发表评论

基于内存查看STL常用容器内容

Kevin Lynx — Wed, 03 Dec 2014 14:08:00 GMT

有时候在线上使用gdb调试程序core问题时，可能没有符号文件，拿到的仅是一个内存地址，如果这个指向的是一个STL对象，那么如何查看这个对象的内容呢？

只需要知道STL各个容器的数据结构实现，就可以查看其内容。本文描述了SGI STL实现中常用容器的数据结构，以及如何在gdb中查看其内容。

string

string，即basic_string bits/basic_string.h：

mutable _Alloc_hider  _M_dataplus;
    ... 
      const _CharT*
      c_str() const
      { return _M_data(); }
    ...    
      _CharT*
      _M_data() const 
      { return  _M_dataplus._M_p; }

    ...
      struct _Alloc_hider : _Alloc
      {
    _Alloc_hider(_CharT* __dat, const _Alloc& __a)
    : _Alloc(__a), _M_p(__dat) { }

    _CharT* _M_p; // The actual data.
      };
   
      size_type
      length() const
      { return _M_rep()->_M_length; }

      _Rep*
      _M_rep() const
      { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }

      ...
       struct _Rep_base
      {
    size_type       _M_length;
    size_type       _M_capacity;
    _Atomic_word        _M_refcount;
      };

      struct _Rep : _Rep_base

即，string内有一个指针，指向实际的字符串位置，这个位置前面有一个_Rep结构，其内保存了字符串的长度、可用内存以及引用计数。当我们拿到一个string对象的地址时，可以通过以下代码获取相关值：

void ds_str_i(void *p) {
        char **raw = (char**)p;
        char *s = *raw;
        size_t len = *(size_t*)(s - sizeof(size_t) * 3);
        printf("str: %s (%zd)\n", s, len);
    }

    size_t ds_str() {
        std::string s = "hello";
        ds_str_i(&s);
        return s.size();
    }

在gdb中拿到一个string的地址时，可以以下打印出该字符串及长度：

(gdb) x/1a p
0x7fffffffe3a0: 0x606028
(gdb) p (char*)0x606028
$2 = 0x606028 "hello"
(gdb) x/1dg 0x606028-24
0x606010:       5

vector

众所周知vector实现就是一块连续的内存，bits/stl_vector.h。

template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
    class vector : protected _Vector_base<_Tp, _Alloc>

    ...
    template<typename _Tp, typename _Alloc>
    struct _Vector_base
    {
      typedef typename _Alloc::template rebind<_Tp>::other _Tp_alloc_type;

      struct _Vector_impl
      : public _Tp_alloc_type
      {
    _Tp*           _M_start;
    _Tp*           _M_finish;
    _Tp*           _M_end_of_storage;
    _Vector_impl(_Tp_alloc_type const& __a)
    : _Tp_alloc_type(__a), _M_start(0), _M_finish(0), _M_end_of_storage(0)
    { }
      };


      _Vector_impl _M_impl;

可以看出sizeof(vector)=24，其内也就是3个指针，_M_start指向首元素地址，_M_finish指向最后一个节点+1，_M_end_of_storage是可用空间最后的位置。

iterator
      end()
      { return iterator (this->_M_impl._M_finish); }
      const_iterator
      ...
      begin() const
      { return const_iterator (this->_M_impl._M_start); }
      ...
      size_type
      capacity() const
      { return size_type(const_iterator(this->_M_impl._M_end_of_storage)
             - begin()); }

可以通过代码从一个vector对象地址输出其信息：

template <typename T>
    void ds_vec_i(void *p) {
        T *start = *(T**)p;
        T *finish = *(T**)((char*)p + sizeof(void*));
        T *end_storage = *(T**)((char*)p + 2 * sizeof(void*));
        printf("vec size: %ld, avaiable size: %ld\n", finish - start, end_storage - start); 
    }

    size_t ds_vec() {
        std::vector<int> vec;
        vec.push_back(0x11);
        vec.push_back(0x22);
        vec.push_back(0x33);
        ds_vec_i<int>(&vec);
        return vec.size();
    }

使用gdb输出一个vector中的内容：

(gdb) p p
$3 = (void *) 0x7fffffffe380
(gdb) x/1a p
0x7fffffffe380: 0x606080
(gdb) x/3xw 0x606080
0x606080:       0x00000011      0x00000022      0x00000033

list

众所周知list被实现为一个链表。准确来说是一个双向链表。list本身是一个特殊节点，其代表end，其指向的下一个元素才是list真正的第一个节点：

bits/stl_list.h

bool
      empty() const
      { return this->_M_impl._M_node._M_next == &this->_M_impl._M_node; }

      const_iterator
      begin() const
      { return const_iterator(this->_M_impl._M_node._M_next); }

      iterator
      end()
      { return iterator(&this->_M_impl._M_node); }

      ...

    struct _List_node_base
    {
        _List_node_base* _M_next;   ///< Self-explanatory
        _List_node_base* _M_prev;   ///< Self-explanatory
        ...
    };
         
    template<typename _Tp>
    struct _List_node : public _List_node_base
    {
      _Tp _M_data;                ///< User's data.
    };
      
    template<typename _Tp, typename _Alloc>
    class _List_base
    {
        ...
      struct _List_impl
      : public _Node_alloc_type
      {
    _List_node_base _M_node;
        ...
      };

      _List_impl _M_impl;

          
    template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
    class list : protected _List_base<_Tp, _Alloc>

所以sizeof(list)=16，两个指针。每一个真正的节点首先是包含两个指针，然后是元素内容(_List_node)。

通过代码输出list的内容：

#define NEXT(ptr, T) do { \
        void *n = *(char**)ptr; \
        T val = *(T*)((char**)ptr + 2); \
        printf("list item %p val: 0x%x\n", ptr, val); \
        ptr = n; \
    } while (0)

    template <typename T>
    void ds_list_i(void *p) {
        void *ptr = *(char**)p;

        NEXT(ptr, T);
        NEXT(ptr, T);
        NEXT(ptr, T);
    }

    size_t ds_list() {
        std::list<int> lst;
        lst.push_back(0x11);
        lst.push_back(0x22);
        lst.push_back(0x33);
        ds_list_i<int>(&lst);
        return lst.size();
    }

在gdb中可以以下方式遍历该list：

(gdb) p p
$4 = (void *) 0x7fffffffe390
(gdb) x/1a p
0x7fffffffe390: 0x606080
(gdb) x/1xw 0x606080+16         # 元素1 
0x606090:       0x00000011
(gdb) x/1a 0x606080
0x606080:       0x6060a0
(gdb) x/1xw 0x6060a0+16         # 元素2
0x6060b0:       0x00000022

map

map使用的是红黑树实现，实际使用的是stl_tree.h实现：

bits/stl_map.h

typedef _Rb_tree<key_type, value_type, _Select1st<value_type>,
               key_compare, _Pair_alloc_type> _Rep_type;
    ...
     _Rep_type _M_t;
    ... 

      iterator
      begin()
      { return _M_t.begin(); }

bits/stl_tree.h

struct _Rb_tree_node_base
      {
        typedef _Rb_tree_node_base* _Base_ptr;
        typedef const _Rb_tree_node_base* _Const_Base_ptr;

        _Rb_tree_color  _M_color;
        _Base_ptr       _M_parent;
        _Base_ptr       _M_left;
        _Base_ptr       _M_right;
        
        ...
      };

    template<typename _Val>
    struct _Rb_tree_node : public _Rb_tree_node_base
    {
      typedef _Rb_tree_node<_Val>* _Link_type;
      _Val _M_value_field;
    };


    template<typename _Key_compare,
           bool _Is_pod_comparator = std::__is_pod<_Key_compare>::__value>
        struct _Rb_tree_impl : public _Node_allocator
        {
      _Key_compare      _M_key_compare;
      _Rb_tree_node_base    _M_header;
      size_type         _M_node_count; // Keeps track of size of tree.
      ...
        }
    
    _Rb_tree_impl<_Compare> _M_impl;
    ...

      iterator
      begin()
      {
    return iterator(static_cast<_Link_type>
            (this->_M_impl._M_header._M_left));
      }

所以可以看出，大部分时候(取决于_M_key_compare) sizeof(map)=48，主要的元素是：

_Rb_tree_color  _M_color; // 节点颜色
        _Base_ptr       _M_parent; // 父节点
        _Base_ptr       _M_left; // 左节点
        _Base_ptr       _M_right; // 右节点
        _Val            _M_value_field // 同list中节点技巧一致，后面是实际的元素

同list中的实现一致，map本身作为一个节点，其不是一个存储数据的节点，

_Rb_tree::end

iterator
      end()
      { return iterator(static_cast<_Link_type>(&this->_M_impl._M_header)); }

由于节点值在_Rb_tree_node_base后，所以任意时候拿到节点就可以偏移这个结构体拿到节点值，节点的值是一个pair，包含了key和value。

在gdb中打印以下map的内容：

size_t ds_map() {
        std::map<std::string, int> imap;
        imap["abc"] = 0xbbb;
        return imap.size();
    }

(gdb) p/x &imap
$7 = 0x7fffffffe370
(gdb) x/1a (char*)&imap+24       # _M_left 真正的节点
0x7fffffffe388: 0x606040          
(gdb) x/1xw 0x606040+32+8        # 偏移32字节是节点值的地址，再偏移8则是value的地址
0x606068:       0x00000bbb
(gdb) p *(char**)(0x606040+32)   # 偏移32字节是string的地址
$8 = 0x606028 "abc"

或者很多时候没有必要这么装逼+蛋疼：

(gdb) p *(char**)(imap._M_t._M_impl._M_header._M_left+1)
$9 = 0x606028 "abc"
(gdb) x/1xw (char*)(imap._M_t._M_impl._M_header._M_left+1)+8
0x606068:       0x00000bbb

完

Kevin Lynx 2014-12-03 22:08 发表评论

linux动态库的种种要点

Kevin Lynx — Mon, 03 Nov 2014 16:55:00 GMT

linux下使用动态库，基本用起来还是很容易。但如果我们的程序中大量使用动态库来实现各种框架/插件，那么就会遇到一些坑，掌握这些坑才有利于程序更稳健地运行。

本篇先谈谈动态库符号方面的问题。

测试代码可以在github上找到

符号查找

一个应用程序test会链接一个动态库libdy.so，如果一个符号，例如函数callfn定义于libdy.so中，test要使用该函数，简单地声明即可：

// dy.cpp libdy.so
void callfn() {
    ...
}

// main.cpp test
extern void callfn();

callfn();

在链接test的时候，链接器会统一进行检查。

同样，在libdy.so中有相同的规则，它可以使用一个外部的符号，在它被链接/载入进一个可执行程序时才会进行符号存在与否的检查。这个符号甚至可以定义在test中，形成一种双向依赖，或定义在其他动态库中：

// dy.cpp libdy.so
extern void mfunc();

mfunc();

// main.cpp test
void mfunc() {
    ...
}

在生成libdy.so时mfunc可以找不到，此时mfunc为未定义：

$ nm libdy.so | grep mfun
U _Z5mfuncv

但在libdy.so被链接进test时则会进行检查，试着把mfunc函数的定义去掉，就会得到一个链接错误：

./libdy.so: undefined reference to `mfunc()'

同样，如果我们动态载入libdy.so，此时当然可以链接通过，但是在载入时同样得到找不到符号的错误：

#ifdef DY_LOAD
    void *dp = dlopen("./libdy.so", RTLD_LAZY);
    typedef void (*callfn)();
    callfn f = (callfn) dlsym(dp, "callfn");
    f();
    dlclose(dp);
#else
    callfn();
#endif

得到错误：

./test: symbol lookup error: ./libdy.so: undefined symbol: _Z5mfuncv

结论：基于以上，我们知道，如果一个动态库依赖了一些外部符号，这些外部符号可以位于其他动态库甚至应用程序中。我们可以再链接这个动态库的时候就把依赖的其他库也链接上，或者推迟到链接应用程序时再链接。而动态加载的库，则要保证在加载该库时，进程中加载的其他动态库里已经存在该符号。

例如，通过LD_PRELOAD环境变量可以让一个进程先加载指定的动态库，上面那个动态加载启动失败的例子，可以通过预先加载包含mfunc符号的动态库解决：

$ LD_PRELOAD=libmfun.so ./test
...

但是如果这个符号存在于可执行程序中则不行：

$ nm test | grep mfunc
0000000000400a00 T _Z5mfuncv
$ nm test | grep mfunc
0000000000400a00 T _Z5mfuncv
$ ./test
...
./test: symbol lookup error: ./libdy.so: undefined symbol: _Z5mfuncv

符号覆盖

前面主要讲的是符号缺少的情况，如果同一个符号存在多分，则更能引发问题。这里谈到的符号都是全局符号，一个进程中某个全局符号始终是全局唯一的。为了保证这一点，在链接或动态载入动态库时，就会出现忽略重复符号的情况。

这里就不提同一个链接单位（如可执行程序、动态库）里符号重复的问题了

函数

当动态库和libdy.so可执行程序test中包含同名的函数时会怎样？根据是否动态加载情况还有所不同。

当直接链接动态库时，libdy.so和test都会链接包含func函数的fun.o，为了区分，我把func按照条件编译得到不同的版本：

// fun.cpp
#ifdef V2
extern "C" void func() {
    printf("func v2\n");
}
#else
extern "C" void func() {
    printf("func v1\n");
}
#endif

// Makefile
test: libdy obj.o mainfn
    g++ -g -Wall -c fun.cpp -o fun.o # 编译为fun.o
    g++ -g -Wall -c main.cpp #-DDY_LOAD
    g++ -g -Wall -o test main.o obj.o fun.o -ldl mfun.o -ldy -L.

libdy: obj
    g++ -Wall -fPIC -c fun.cpp -DV2 -o fun-dy.o  # 定义V2宏，编译为fun-dy.o
    g++ -Wall -fPIC -shared -o libdy.so dy.cpp -g obj.o fun-dy.o

这样，test中的func就会输出func v1；libdy.so中的func就会输出func v2。test和libdy.o确实都有func符号：

$ nm libdy.so | grep func
0000000000000a60 T func

$nm test | grep func
0000000000400a80 T func

在test和libdy.so中都会调用func函数：

// main.cpp test
int main(int argc, char **argv) {
    func();
    ...
    callfn(); // 调用libdy.so中的函数
    ...
}

// dy.cpp libdy.so
extern "C" void callfn() {
    ... 
    printf("callfn\n");
    func();
    ...
}

运行后发现，都调用的是同一个func：

$ ./test
...
func v1
...
callfn
func v1

结论，直接链接动态库时，整个程序运行的时候符号会发生覆盖，只有一个符号被使用。在实践中，如果程序和链接的动态库都依赖了一个静态库，而后他们链接的这个静态库版本不同，则很有可能因为符号发生了覆盖而导致问题。(静态库同普通的.o性质一样，参考浅析静态库链接原理)

更复杂的情况中，多个动态库和程序都有相同的符号，情况也是一样，会发生符号覆盖。如果程序里没有这个符号，而多个动态库里有相同的符号，也会覆盖。

但是对于动态载入的情况则不同，同样的libdy.so我们在test中不链接，而是动态载入：

int main(int argc, char **argv) {
    func();
#ifdef DY_LOAD
    void *dp = dlopen("./libdy.so", RTLD_LAZY);
    typedef void (*callfn)();
    callfn f = (callfn) dlsym(dp, "callfn");
    f();
    func();
    dlclose(dp);
#else
    callfn();
#endif
    return 0;
}

运行得到：

$ ./test
func v1
...
callfn
func v2
func v1

都正确地调用到各自链接的func。

结论，实践中，动态载入的动态库一般会作为插件使用，那么其同程序链接不同版本的静态库（相同符号不同实现），是没有问题的。

变量

变量本质上也是符号(symbol)，但其处理规则和函数还有点不一样(是不是有点想吐槽了)。

// object.h
class Object {
public:
    Object() {
#ifdef DF
        s = malloc(32);
        printf("s addr %p\n", s);
#endif
        printf("ctor %p\n", this);
    }

    ~Object() {
        printf("dtor %p\n", this);
#ifdef DF
        printf("s addr %p\n", s);
        free(s);
#endif
    }

    void *s;
};

extern Object g_obj;

我们的程序test和动态库libdy.so都会链接object.o。首先测试test链接libdy.so，test和libdy.so中都会有g_obj这个符号：

// B g_obj 表示g_obj位于BSS段，未初始化段

$ nm test | grep g_obj
0000000000400a14 t _GLOBAL__I_g_obj
00000000006012c8 B g_obj
$ nm libdy.so | grep g_obj
000000000000097c t _GLOBAL__I_g_obj
0000000000200f30 B g_obj

运行：

$ ./test
ctor 0x6012c8
ctor 0x6012c8
...
dtor 0x6012c8
dtor 0x6012c8

g_obj被构造了两次，但地址一样。全局变量只有一个实例，似乎在情理之中。

动态载入libdy.so，变量地址还是相同的：

$ ./test
ctor 0x6012a8
...
ctor 0x6012a8
...
dtor 0x6012a8
dtor 0x6012a8

结论，不同于函数，全局变量符号重复时，不论动态库是动态载入还是直接链接，变量始终只有一个。

但诡异的情况是，对象被构造和析构了两次。构造两次倒无所谓，浪费点空间，但是析构两次就有问题。因为析构时都操作的是同一个对象，那么如果这个对象内部有分配的内存，那就会对这块内存造成double free，因为指针相同。打开DF宏实验下：

$ ./test
s addr 0x20de010
ctor 0x6012b8
s addr 0x20de040
ctor 0x6012b8
...
dtor 0x6012b8
s addr 0x20de040
dtor 0x6012b8
s addr 0x20de040

因为析构的两次都是同一个对象，所以其成员s指向的内存被释放了两次，从而产生了double free，让程序coredump了。

总结，全局变量符号重复时，始终会只使用一个，并且会被初始化/释放两次，是一种较危险的情况，应当避免在使用动态库的过程中使用全局变量。

完

Kevin Lynx 2014-11-04 00:55 发表评论

浅析glibc中thread tls的一处bug

Kevin Lynx — Tue, 07 Oct 2014 13:38:00 GMT

最早的时候是在程序初始化过程中开启了一个timer(timer_create)，这个timer第一次触发的时间较短时就会引起程序core掉，core的位置也是不定的。使用valgrind可以发现有错误的内存写入：

==31676== Invalid write of size 8
==31676==    at 0x37A540F852: _dl_allocate_tls_init (in /lib64/ld-2.5.so)
==31676==    by 0x4E26BD3: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so)
==31676==    by 0x76E0B00: timer_helper_thread (in /lib64/librt-2.5.so)
==31676==    by 0x4E2673C: start_thread (in /lib64/libpthread-2.5.so)
==31676==    by 0x58974BC: clone (in /lib64/libc-2.5.so)
==31676==  Address 0xf84dbd0 is 0 bytes after a block of size 336 alloc'd
==31676==    at 0x4A05430: calloc (vg_replace_malloc.c:418)
==31676==    by 0x37A5410082: _dl_allocate_tls (in /lib64/ld-2.5.so)
==31676==    by 0x4E26EB8: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so)
==31676==    by 0x76E0B00: timer_helper_thread (in /lib64/librt-2.5.so)
==31676==    by 0x4E2673C: start_thread (in /lib64/libpthread-2.5.so)
==31676==    by 0x58974BC: clone (in /lib64/libc-2.5.so)

google _dl_allocate_tls_init 相关发现一个glibc的bug Bug 13862 和我的情况有点类似。本文就此bug及tls相关实现做一定阐述。

需要查看glibc的源码，如何确认使用的glibc的版本，可以这样：

$ /lib/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
...

为了方便，还可以直接在(glibc Cross Reference)[http://osxr.org/glibc/source/?v=glibc-2.17]网页上进行查看，版本不同，但影响不大。

BUG描述

要重现13862 BUG作者提到要满足以下条件：

The use of a relatively large number of dynamic libraries, loaded at runtime using dlopen.

The use of thread-local-storage within those libraries.

A thread exiting prior to the number of loaded libraries increasing a significant amount, followed by a new thread being created after the number of libraries has increased.

简单来说，就是在加载一大堆包含TLS变量的动态库的过程中，开启了一个线程，这个线程退出后又开启了另一个线程。

这和我们的问题场景很相似。不同的是我们使用的是timer，但timer在触发时也是开启新的线程，并且这个线程会立刻退出：

/nptl/sysdeps/unix/sysv/linux/timer_routines.c

timer_helper_thread(...)  // 用于检测定时器触发的辅助线程
{
    ...
      pthread_t th;
      (void) pthread_create (&th, &tk->attr, timer_sigev_thread, // 开启一个新线程调用用户注册的定时器函数
                 td);
    ...
}

要重现此BUG可以使用我的实验代码 thread-tls，或者使用Bug 13862 中的附件

TLS相关实现

可以顺着_dl_allocate_tls_init函数的实现查看相关联的部分代码。该函数遍历所有加载的包含TLS变量的模块，初始化一个线程的TLS数据结构。

每一个线程都有自己的堆栈空间，其中单独存储了各个模块的TLS变量，从而实现TLS变量在每一个线程中都有单独的拷贝。TLS与线程的关联关系可以查看下图：

应用层使用的pthread_t实际是个pthread对象的地址。创建线程时线程的堆栈空间和pthread结构是一块连续的内存。但这个地址并不指向这块内存的首地址。相关代码：/nptl/allocatestack.c allocate_stack，该函数分配线程的堆栈内存。

pthread第一个成员是tcbhead_t，tcbhead_t中dtv指向了一个dtv_t数组，该数组的大小随着当前程序载入的模块多少而动态变化。每一个模块被载入时，都有一个l_tls_modid，其直接作为dtv_t数组的下标索引。tcbhead_t中的dtv实际指向的是dtv_t第二个元素，第一个元素用于记录整个dtv_t数组有多少元素，第二个元素也做特殊使用，从第三个元素开始，才是用于存储TLS变量。

一个dtv_t存储的是一个模块中所有TLS变量的地址，当然这些TLS变量都会被放在连续的内存空间里。dtv_t::pointer::val正是用于指向这块内存的指针。对于非动态加载的模块它指向的是线程堆栈的位置；否则指向动态分配的内存位置。

以上结构用代码描述为，

union dtv_t {
    size_t counter;
    struct {
        void *val; /* point to tls variable memory */
        bool is_static;
    } pointer;
};
 
struct tcbhead_t {
    void *tcb;
    dtv_t *dtv; /* point to a dtv_t array */
    void *padding[22]; /* other members i don't care */
};

struct pthread {
    tcbhead_t tcb;
    /* more members i don't care */
};

dtv是一个用于以模块为单位存储TLS变量的数组。

实际代码参看 /nptl/descr.h 及 nptl/sysdeps/x86_64/tls.h。

实验

使用g++ -o thread -g -Wall -lpthread -ldl thread.cpp编译代码，即在创建线程前加载了一个.so：

Breakpoint 1, dump_pthread (id=1084229952) at thread.cpp:40
40          printf("pthread %p, dtv %p\n", pd, dtv);
(gdb) set $dtv=pd->tcb.dtv
(gdb) p $dtv[-1]
$1 = {counter = 17, pointer = {val = 0x11, is_static = false}}
(gdb) p $dtv[3]
$2 = {counter = 18446744073709551615, pointer = {val = 0xffffffffffffffff, is_static = false}}

dtv[3]对应着动态加载的模块，is_static=false，val被初始化为-1：

/elf/dl-tls.c _dl_allocate_tls_init

if (map->l_tls_offset == NO_TLS_OFFSET
   || map->l_tls_offset == FORCED_DYNAMIC_TLS_OFFSET)
 {
   /* For dynamically loaded modules we simply store
      the value indicating deferred allocation.  */
   dtv[map->l_tls_modid].pointer.val = TLS_DTV_UNALLOCATED;
   dtv[map->l_tls_modid].pointer.is_static = false;
   continue;
 }

dtv数组大小之所以为17，可以参看代码 /elf/dl-tls.c allocate_dtv：

// dl_tls_max_dtv_idx 随着载入模块的增加而增加，载入1个.so则是1 

dtv_length = GL(dl_tls_max_dtv_idx) + DTV_SURPLUS; // DTV_SURPLUS 14
dtv = calloc (dtv_length + 2, sizeof (dtv_t));
if (dtv != NULL)
 {
   /* This is the initial length of the dtv.  */
   dtv[0].counter = dtv_length;

继续上面的实验，当调用到.so中的function时，其TLS被初始化，此时dtv[3]中val指向初始化后的TLS变量地址：

68          fn();
(gdb)
0x601808, 0x601804, 0x601800
72          return 0;
(gdb) p $dtv[3]
$3 = {counter = 6297600, pointer = {val = 0x601800, is_static = false}}
(gdb) x/3xw 0x601800
0x601800:       0x55667788      0xaabbccdd      0x11223344

这个时候还可以看看dtv[1]中的内容，正是指向了pthread前面的内存位置：

(gdb) p $dtv[1]
$5 = {counter = 1084229936, pointer = {val = 0x40a00930, is_static = true}}
(gdb) p/x tid
$7 = 0x40a00940

结论:

线程中TLS变量的存储是以模块为单位的

so模块加载

这里也并不太需要查看dlopen等具体实现，由于使用__thread来定义TLS变量，整个实现涉及到ELF加载器的一些细节，深入下去内容较多。这里直接通过实验的手段来了解一些实现即可。

上文已经看到，在创建线程前如果动态加载了.so，dtv数组的大小是会随之增加的。如果是在线程创建后再载入.so呢？

使用g++ -o thread -g -Wall -lpthread -ldl thread.cpp -DTEST_DTV_EXPAND -DSO_CNT=1编译程序，调试得到：

73          load_sos();
(gdb)
0x601e78, 0x601e74, 0x601e70

Breakpoint 1, dump_pthread (id=1084229952) at thread.cpp:44
44          printf("pthread %p, dtv %p\n", pd, dtv);
(gdb) p $dtv[-1]
$3 = {counter = 17, pointer = {val = 0x11, is_static = false}}
(gdb) p $dtv[4]
$4 = {counter = 6299248, pointer = {val = 0x601e70, is_static = false}}

在新载入了.so时，dtv数组大小并没有新增，dtv[4]直接被拿来使用。

因为dtv初始大小为16，那么当载入的.so超过这个数字的时候会怎样？

使用g++ -o thread -g -Wall -lpthread -ldl thread.cpp -DTEST_DTV_EXPAND编译程序：

...
pthread 0x40a00940, dtv 0x6016a0
...
Breakpoint 1, dump_pthread (id=1084229952) at thread.cpp:44
44          printf("pthread %p, dtv %p\n", pd, dtv);
(gdb) p dtv
$2 = (dtv_t *) 0x6078a0
(gdb) p dtv[-1]
$3 = {counter = 32, pointer = {val = 0x20, is_static = false}}
(gdb) p dtv[5]
$4 = {counter = 6300896, pointer = {val = 0x6024e0, is_static = false}}

可以看出，dtv被重新分配了内存(0x6016a0 -> 0x6078a0)并做了扩大。

以上得出结论：

创建线程前dtv的大小会根据载入模块数量决定
创建线程后新载入的模块会动态扩展dtv的大小(必要的时候)

pthread堆栈重用

在allocate_stack中分配线程堆栈时，有一个从缓存中取的操作：

allocate_stack(..) {
    ...
    pd = get_cached_stack (&size, &mem);
    ...
}
/* Get a stack frame from the cache.  We have to match by size since
   some blocks might be too small or far too large.  */
get_cached_stack(...) {
    ...
    list_for_each (entry, &stack_cache) // 根据size从stack_cache中取
    { ... }
    ...
    /* Clear the DTV.  */
    dtv_t *dtv = GET_DTV (TLS_TPADJ (result));
    for (size_t cnt = 0; cnt < dtv[-1].counter; ++cnt)
        if (! dtv[1 + cnt].pointer.is_static
                && dtv[1 + cnt].pointer.val != TLS_DTV_UNALLOCATED)
            free (dtv[1 + cnt].pointer.val);
    memset (dtv, '\0', (dtv[-1].counter + 1) * sizeof (dtv_t));

    /* Re-initialize the TLS.  */
    _dl_allocate_tls_init (TLS_TPADJ (result));
}

get_cached_stack会把取出的pthread中的dtv重新初始化。注意 _dl_allocate_tls_init 中是根据模块列表来初始化dtv数组的。

实验

当一个线程退出后，它就可能被当做cache被get_cached_stack取出复用。

使用g++ -o thread -g -Wall -lpthread -ldl thread.cpp -DTEST_CACHE_STACK编译程序，运行：

$ ./thread
..
pthread 0x413c9940, dtv 0x1be46a0
... 
pthread 0x413c9940, dtv 0x1be46a0

回顾BUG

当新创建的线程复用了之前退出的线程堆栈时，由于在_dl_allocate_tls_init中初始化dtv数组时是根据当前载入的模块数量而定。如果在这个时候模块数已经超过了这个复用的dtv数组大小，那么就会出现写入非法的内存。使用valgrind检测就会得到本文开头提到的结果。

由于dtv数组大小通常会稍微大点，所以在新加载的模块数量不够多时程序还不会有问题。可以通过控制测试程序中SO_CNT的大小看看dtv中内容的变化。

另外，我查看了下glibc的更新历史，到目前为止(2.20)这个BUG还没有修复。

参考文档

Kevin Lynx 2014-10-07 21:38 发表评论

浅析静态库链接原理

Kevin Lynx — Mon, 15 Sep 2014 14:47:00 GMT

静态库的链接基本上同链接目标文件.obj/.o相同，但也有些不同的地方。本文简要描述linux下静态库在链接过程中的一些细节。

静态库文件格式

静态库远远不同于动态库，不涉及到符号重定位之类的问题。静态库本质上只是将一堆目标文件进行打包而已。静态库没有标准，不同的linux下都会有些细微的差别。大致的格式wiki上描述的较清楚：

Global header
-----------------        +-------------------------------
File header 1       ---> | File name
File content 1  |        | File modification timestamp 
-----------------        | Owner ID
File header 2            | Group ID
File content 2           | File mode
-----------------        | File size in bytes
...                      | File magic
                         +-------------------------------

File header很多字段都是以ASCII码表示，所以可以用文本编辑器打开。

静态库本质上就是使用ar命令打包一堆.o文件。我们甚至可以用ar随意打包一些文件：

$ echo 'hello' > a.txt && echo 'world' > b.txt
$ ar -r test.a a.txt b.txt
$ cat test.a
!
a.txt/          1410628755  60833 100   100644  6         `
hello
b.txt/          1410628755  60833 100   100644  6         `
world

链接过程

链接器在链接静态库时，同链接一般的.o基本相似。链接过程大致可以归纳下图：

总结为：

所有传入链接器的.o都会被链接进最终的可执行程序；链接.o时，会将.o中的global symbol和unresolved symbol放入一个临时表
如果多个.o定义了相同的global symbol，那么就会得到多重定义的链接错误
如果链接结束了，unresolved symbol表不为空，那么就会得到符号未定义的链接错误
.a静态库处理本质上就是处理其中的每一个.o，不同的是，如果某个.o中没有一个符号属于unresolved symbol表，也就是链接器此时怀疑该.o没有必要，那么其就会被忽略

可以通过一些代码来展示以上过程。在开发C++程序时，可以利用文件静态变量会先于main之前执行做一些可能利于程序结构的事情。如果某个.o（包含静态库中打包的.o）被链接进程序，那么其文件静态变量就会先于main初始化。

// test.cpp
#include 

class Test {
public:
    Test() {
        printf("Test ctor\n");
    }
};

static Test s_test;

// lib.cpp
#include 

class Lib {
public:
    Lib() {
        printf("Lib ctor\n");
    }
};

static Lib s_lib;

// main.cpp
#include 

int main() {
    printf("main\n");
    return 0;
}

以上代码main.cpp中未引用任何test.cpp``lib.cpp中的符号：

$ g++ -o test test.o lib.o main.o
$ ./test
Lib ctor
Test ctor
main

生成的可执行程序执行如预期，其链接了test.o``lib.o。但是如果把lib.o以静态库的形式进行链接，情况就不一样了：为了做对比，基于以上的代码再加一个文件，及修改main.cpp：

// libfn.cpp
int sum(int a, int b) {
    return a + b;
}

// main.cpp
#include 

int main() {
    printf("main\n");
    extern int sum(int, int);
    printf("sum: %d\n", sum(2, 3));
    return 0;
}

将libfn.o和lib.o创建为静态库：

$ ar -r libfn.a libfn.o lib.o
$ g++ -o test main.o test.o -lfn -L.
$ ./test
Test ctor
main
sum: 5

因为lib.o没有被链接，导致其文件静态变量也未得到初始化。

调整链接顺序，可以进一步检验前面的链接过程：

# 将libfn.a的链接放在main.o前面

$ g++ -o test test.o -lfn main.o  -L.
main.o: In function `main':
main.cpp:(.text+0x19): undefined reference to `sum(int, int)'
collect2: ld returned 1 exit status

这个问题遇到得比较多，也有点让人觉得莫名其妙。其原因就在于链接器在链接libfn.a的时候，发现libfn.o依然没有被之前链接的*.o引用到，也就是没有任何符号在unresolved symbol table中，所以libfn.o也被忽略。

一些实践

在实际开发中还会遇到一些静态库相关的问题。

链接顺序问题

前面的例子已经展示了这个问题。调整库的链接顺序可以解决大部分问题，但当静态库之间存在环形依赖时，则无法通过调整顺序来解决。

-whole-archive

-whole-archive选项告诉链接器把静态库中的所有.o都进行链接，针对以上例子：

$ g++ -o test -L. test.o -Wl,--whole-archive -lfn main.o -Wl,--no-whole-archive
$ ./test
Lib ctor
Test ctor
main
sum: 5

连lib.o也被链接了进来。-Wl选项告诉gcc将其作为链接器参数传入；之所以在命令行结尾加上--no-whole-archive是为了告诉编译器不要链接gcc默认的库

可以看出这个方法还是有点暴力了。

–start-group

格式为：

--start-group archives --end-group

位于--start-group --end-group中的所有静态库将被反复搜索，而不是默认的只搜索一次，直到不再有新的unresolved symbol产生为止。也就是说，出现在这里的.o如果发现有unresolved symbol，则可能回到之前的静态库中继续搜索。

$ g++ -o test -L. test.o -Wl,--start-group -lfn main.o -Wl,--end-group
$ ./test
Test ctor
main
sum: 5

查看ldd关于该参数的man page还可以一窥链接过程的细节：

The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved.

嵌套静态库

由于ar创建静态库时本质上只是对文件进行打包，所以甚至可以创建一个嵌套的静态库，从而测试链接器是否会递归处理静态库中的.o：

$ ar -r libfn.a libfn.o
$ ar -r liboutfn.a libfn.a lib.o
$ g++ -o test -L. test.o main.o -loutfn
main.o: In function `main':
main.cpp:(.text+0x19): undefined reference to `sum(int, int)'
collect2: ld returned 1 exit status

可见链接器并不会递归处理静态库中的文件

之所以要提到嵌套静态库这个问题，是因为我发现很多时候我们喜欢为一个静态库工程链接其他静态库。当然，这里的链接并非真正的链接（仅是打包），这个过程当然可以聪明到将其他静态库里的.o提取出来然后打包到新的静态库。

如果我们使用的是类似scons这种封装更高的依赖项管理工具，那么它是否会这样干呢？

基于之前的例子，我们使用scons来创建liboutfn.a：

# Sconstruct
StaticLibrary('liboutfn.a', ['libfn.a', 'lib.o'])

使用文本编辑器打开liboutfn.a就可以看到其内容，或者使用：

$ ar -tv liboutfn.a
rw-r--r-- 60833/100   1474 Sep 14 02:59 2014 libfn.a
rw-r--r-- 60833/100   2448 Sep 14 02:16 2014 lib.o

可见scons也只是单纯地打包。所以，在scons中构建一个静态库时，再链接其他静态库是没有意义的

参考文档

Kevin Lynx 2014-09-15 22:47 发表评论

C/C++中手动获取调用堆栈

Kevin Lynx — Tue, 02 Sep 2014 14:14:00 GMT

当我们的程序core掉之后，如果能获取到core时的函数调用堆栈将非常有利于定位问题。在Windows下可以使用SEH机制；在Linux下通过gdb使用coredump文件即可。

但有时候由于某些错误导致堆栈被破坏，发生拿不到调用堆栈的情况。

一些基础预备知识本文不再详述，可以参考以下文章：

需要知道的信息：

函数调用对应的call指令本质上是先压入下一条指令的地址到堆栈，然后跳转到目标函数地址
函数返回指令ret则是从堆栈取出一个地址，然后跳转到该地址
EBP寄存器始终指向当前执行函数相关信息（局部变量）所在栈中的位置，ESP则始终指向栈顶
每一个函数入口都会保存调用者的EBP值，在出口处都会重设EBP值，从而实现函数调用的现场保存及现场恢复
64位机器增加了不少寄存器，从而使得函数调用的参数大部分时候可以通过寄存器传递；同时寄存器名字发生改变，例如EBP变为RBP

在函数调用中堆栈的情况可用下图说明：

将代码对应起来：

    void g() {
        int *p = 0;
        long a = 0x1234;
        printf("%p %x\n", &a, a);
        printf("%p %x\n", &p, p);
        f();
        *p = 1;
    }
    void b(int argc, char **argv) {
        printf("%p %p\n", &argc, &argv);
        g();
    }
    int main(int argc, char **argv) {
        b(argc, argv);
        return 0;
    }

在函数g()中断点，看看堆栈中的内容(64位机器)：

(gdb) p $rbp
$2 = (void *) 0x7fffffffe370
(gdb) p &p
$3 = (int **) 0x7fffffffe368
(gdb) p $rsp
$4 = (void *) 0x7fffffffe360
(gdb) x/8ag $rbp-16
0x7fffffffe360: 0x1234  0x0
0x7fffffffe370: 0x7fffffffe390  0x400631 
0x7fffffffe380: 0x7fffffffe498  0x1a561cbc0
0x7fffffffe390: 0x7fffffffe3b0  0x40064f

对应的堆栈图：

可以看看例子中0x400631 和0x40064f 中的代码：

(gdb) disassemble 0x400631
...
0x0000000000400627 : callq  0x400468 
0x000000000040062c : callq  0x4005ae 
0x0000000000400631 : leaveq                           # call的下一条指令
...
(gdb) disassemble 0x40064f
... 
0x000000000040063f :      mov    %rsi,-0x10(%rbp)
0x0000000000400643 :      mov    -0x10(%rbp),%rsi
0x0000000000400647 :      mov    -0x4(%rbp),%edi
0x000000000040064a :      callq  0x400606 
0x000000000040064f :      mov    $0x0,%eax         # call的下一条指令
...

顺带一提，每个函数入口和出口，对应的设置RBP代码为：

(gdb) disassemble g
...
0x00000000004005ae :     push   %rbp               # 保存调用者的RBP到堆栈
0x00000000004005af :     mov    %rsp,%rbp          # 设置自己的RBP
...
0x0000000000400603 :    leaveq                    # 等同于：movq %rbp, %rsp
                                                          #         popq %rbp
0x0000000000400604 :    retq

由以上可见，通过当前的RSP或RBP就可以找到调用堆栈中所有函数的RBP；找到了RBP就可以找到函数地址。因为，任何时候的RBP指向的堆栈位置就是上一个函数的RBP；而任何时候RBP所在堆栈中的前一个位置就是函数返回地址。

由此我们可以自己构建一个导致gdb无法取得调用堆栈的例子：

    void f() {
        long *p = 0;
        p = (long*) (&p + 1); // 取得g()的RBP
        *p = 0;  // 破坏g()的RBP
    }
    void g() {
        int *p = 0;
        long a = 0x1234;
        printf("%p %x\n", &a, a);
        printf("%p %x\n", &p, p);
        f();
        *p = 1; // 写0地址导致一次core
    }
    void b(int argc, char **argv) {
        printf("%p %p\n", &argc, &argv);
        g();
    }
    int main(int argc, char **argv) {
        b(argc, argv);
        return 0;
    }

使用gdb运行该程序：

Program received signal SIGSEGV, Segmentation fault.
g () at ebp.c:37
37          *p = 1;
(gdb) bt
Cannot access memory at address 0x8
(gdb) p $rbp
$1 = (void *) 0x0

bt无法获取堆栈，在函数g()中RBP被改写为0，gdb从0偏移一个地址长度即0x8，尝试从0x8内存位置获取函数地址，然后提示Cannot access memory at address 0x8。

RBP出现了问题，我们就可以通过RSP来手动获取调用堆栈。因为RSP是不会被破坏的，要通过RSP获取调用堆栈则需要偏移一些局部变量所占的空间：

(gdb) p $rsp
$2 = (void *) 0x7fffffffe360
(gdb) x/8ag $rsp+16             # g()中局部变量占16字节
0x7fffffffe370: 0x7fffffffe390  0x400631 
0x7fffffffe380: 0x7fffffffe498  0x1a561cbc0
0x7fffffffe390: 0x7fffffffe3b0  0x40064f 
0x7fffffffe3a0: 0x7fffffffe498  0x100000000

基于以上就可以手工找到调用堆栈：

g()
0x400631 
0x40064f

上面的例子本质上也是破坏堆栈，并且仅仅破坏了保存了的RBP。在实际情况中，堆栈可能会被破坏得更多，则可能导致手动定位也较困难。

堆栈被破坏还可能导致更多的问题，例如覆盖了函数返回地址，则会导致RIP错误；例如堆栈的不平衡。导致堆栈被破坏的原因也有很多，例如局部数组越界；delete/free栈上对象等。

omit-frame-pointer

使用RBP获取调用堆栈相对比较容易。但现在编译器都可以设置不使用RBP(gcc使用-fomit-frame-pointer，msvc使用/Oy)，对于函数而言不设置其RBP意味着可以节省若干条指令。在函数内部则完全使用RSP的偏移来定位局部变量，包括嵌套作用域里的局部变量，即使程序实际运行时不会进入这个作用域。

例如：

    void f2() {
        int a = 0x1234;
        if (a > 0) {
            int b = 0xff;
            b = a;
        }
    }

gcc中使用-fomit-frame-pointer生成的代码为：

(gdb) disassemble f2
Dump of assembler code for function f2:
0x00000000004004a5 :      movl   $0x1234,-0x8(%rsp)    # int a = 0x1234
0x00000000004004ad :      cmpl   $0x0,-0x8(%rsp)       
0x00000000004004b2 :     jle    0x4004c4       
0x00000000004004b4 :     movl   $0xff,-0x4(%rsp)      # int b = 0xff
0x00000000004004bc :     mov    -0x8(%rsp),%eax
0x00000000004004c0 :     mov    %eax,-0x4(%rsp)
0x00000000004004c4 :     retq

可以发现f2()没有操作RBP之类的指令了。

Kevin Lynx 2014-09-02 22:14 发表评论

基于protobuf的RPC实现

Kevin Lynx — Sun, 31 Aug 2014 11:40:00 GMT

可以对照使用google protobuf RPC实现echo service一文看，细节本文不再描述。

google protobuf只负责消息的打包和解包，并不包含RPC的实现，但其包含了RPC的定义。假设有下面的RPC定义：

service MyService {
        rpc Echo(EchoReqMsg) returns(EchoRespMsg) 
    }

那么要实现这个RPC需要最少做哪些事？总结起来需要完成以下几步：

客户端

RPC客户端需要实现google::protobuf::RpcChannel。主要实现RpcChannel::CallMethod接口。客户端调用任何一个RPC接口，最终都是调用到CallMethod。这个函数的典型实现就是将RPC调用参数序列化，然后投递给网络模块进行发送。

void CallMethod(const ::google::protobuf::MethodDescriptor* method,
                  ::google::protobuf::RpcController* controller,
                  const ::google::protobuf::Message* request,
                  ::google::protobuf::Message* response,
                  ::google::protobuf::Closure* done) {
        ...
        DataBufferOutputStream outputStream(...) // 取决于你使用的网络实现
        request->SerializeToZeroCopyStream(&outputStream);
        _connection->postData(outputStream.getData(), ...
        ...
    }

服务端

服务端首先需要实现RPC接口，直接实现MyService中定义的接口：

class MyServiceImpl : public MyService {
        virtual void Echo(::google::protobuf::RpcController* controller,
            const EchoReqMsg* request,
            EchoRespMsg* response,
            ::google::protobuf::Closure* done) {
            ...
            done->Run();
        }
    }

标示service&method

基于以上，可以看出服务端根本不知道客户端想要调用哪一个RPC接口。从服务器接收到网络消息，到调用到MyServiceImpl::Echo还有很大一段距离。

解决方法就是在网络消息中带上RPC接口标识。这个标识可以直接带上service name和method name，但这种实现导致网络消息太大。另一种实现是基于service name和method name生成一个哈希值，因为接口不会太多，所以较容易找到基本不冲突的字符串哈希算法。

无论哪种方法，服务器是肯定需要建立RPC接口标识到protobuf service对象的映射的。

这里提供第三种方法：基于option的方法。

protobuf中option机制类似于这样一种机制：service&method被视为一个对象，其有很多属性，属性包含内置的，以及用户扩展的。用户扩展的就是option。每一个属性有一个值。protobuf提供访问service&method这些属性的接口。

首先扩展service&method的属性，以下定义这些属性的key：

extend google.protobuf.ServiceOptions {
      required uint32 global_service_id = 1000; 
    }
    extend google.protobuf.MethodOptions {
      required uint32 local_method_id = 1000;
    }

应用层定义service&method时可以指定以上key的值：

service MyService
    {
        option (arpc.global_service_id) = 2302; 

        rpc Echo(EchoReqMsg) returns(EchoRespMsg) 
        {
            option (arpc.local_method_id) = 1;
        }
        rpc Echo_2(EchoReqMsg) returns(EchoRespMsg) 
        {
            option (arpc.local_method_id) = 2;
        }
        ...
    }

以上相当于在整个应用中，每个service都被赋予了唯一的id，单个service中的method也有唯一的id。

然后可以通过protobuf取出以上属性值：

void CallMethod(const ::google::protobuf::MethodDescriptor* method,
                  ::google::protobuf::RpcController* controller,
                  const ::google::protobuf::Message* request,
                  ::google::protobuf::Message* response,
                  ::google::protobuf::Closure* done) {
        ...
        google::protobuf::ServiceDescriptor *service = method->service();
        uint32_t serviceId = (uint32_t)(service->options().GetExtension(global_service_id));
        uint32_t methodId = (uint32_t)(method->options().GetExtension(local_method_id));
        ...
    }

考虑到serviceId methodId的范围，可以直接打包到一个32位整数里：

uint32_t ret = (serviceId << 16) | methodId;

然后就可以把这个值作为网络消息头的一部分发送。

当然服务器端是需要建立这个标识值到service的映射的：

bool MyRPCServer::registerService(google::protobuf::Service *rpcService) {
        const google::protobuf::ServiceDescriptor = rpcService->GetDescriptor();
        int methodCnt = pSerDes->method_count();

        for (int i = 0; i < methodCnt; i++) {
            google::protobuf::MethodDescriptor *pMethodDes = pSerDes->method(i);
            uint32_t rpcCode = PacketCodeBuilder()(pMethodDes); // 计算出映射值
            _rpcCallMap[rpcCode] = make_pair(rpcService, pMethodDes); // 建立映射
        }
        return true;
    }

服务端收到RPC调用后，取出这个标识值，然后再从_rpcCallMap中取出对应的service和method，最后进行调用：

google::protobuf::Message* response = _pService->GetResponsePrototype(_pMethodDes).New();
    // 用于回应的closure
    RPCServerClosure *pClosure = new (nothrow) RPCServerClosure( 
            _channelId, _pConnection, _pReqMsg, pResMsg, _messageCodec, _version);
    RPCController *pController = pClosure->GetRpcController();
    ...
    // protobuf 生成的CallMethod，会自动调用到Echo接口
    _pService->CallMethod(_pMethodDes, pController, _pReqMsg, pResMsg, pClosure);

参考

Kevin Lynx 2014-08-31 19:40 发表评论

Muduo源码阅读

Kevin Lynx — Sun, 04 May 2014 10:22:00 GMT

最近简单读了下muduo的源码，本文对其主要实现/结构简单总结下。

muduo的主要源码位于net文件夹下，base文件夹是一些基础代码，不影响理解网络部分的实现。muduo主要类包括：

EventLoop
Channel
Poller
TcpConnection
TcpClient
TcpServer
Connector
Acceptor
EventLoopThread
EventLoopThreadPool

其中，Poller（及其实现类）包装了Poll/EPoll，封装了OS针对设备(fd)的操作；Channel是设备fd的包装，在muduo中主要包装socket；TcpConnection抽象一个TCP连接，无论是客户端还是服务器只要建立了网络连接就会使用TcpConnection；TcpClient/TcpServer分别抽象TCP客户端和服务器；Connector/Acceptor分别包装TCP客户端和服务器的建立连接/接受连接；EventLoop是一个主控类，是一个事件发生器，它驱动Poller产生/发现事件，然后将事件派发到Channel处理；EventLoopThread是一个带有EventLoop的线程；EventLoopThreadPool自然是一个EventLoopThread的资源池，维护一堆EventLoopThread。

阅读库源码时可以从库的接口层着手，看看关键功能是如何实现的。对于muduo而言，可以从TcpServer/TcpClient/EventLoop/TcpConnection这几个类着手。接下来看看主要功能的实现：

建立连接

    TcpClient::connect 
        -> Connector::start 
            -> EventLoop::runInLoop(Connector::startInLoop...
            -> Connector::connect

EventLoop::runInLoop接口用于在this所在的线程运行某个函数，这个后面看下EventLoop的实现就可以了解。网络连接的最终建立是在Connector::connect中实现，建立连接之后会创建一个Channel来代表这个socket，并且绑定事件监听接口。最后最重要的是，调用Channel::enableWriting。Channel有一系列的enableXX接口，这些接口用于标识自己关心某IO事件。后面会看到他们的实现。

Connector监听的主要事件无非就是连接已建立，用它监听读数据/写数据事件也不符合设计。TcpConnection才是做这种事的。

客户端收发数据

当Connector发现连接真正建立好后，会回调到TcpClient::newConnection，在TcpClient构造函数中：

    connector_->setNewConnectionCallback(
      boost::bind(&TcpClient::newConnection, this, _1));

TcpClient::newConnection中创建一个TcpConnection来代表这个连接：

    TcpConnectionPtr conn(new TcpConnection(loop_,
                                            connName,
                                            sockfd,
                                            localAddr,
                                            peerAddr));

    conn->setConnectionCallback(connectionCallback_);
    conn->setMessageCallback(messageCallback_);
    conn->setWriteCompleteCallback(writeCompleteCallback_);
    ...
    conn->connectEstablished();

并同时设置事件回调，以上设置的回调都是应用层（即库的使用者）的接口。每一个TcpConnection都有一个Channel，毕竟每一个网络连接都对应了一个socket fd。在TcpConnection构造函数中创建了一个Channel，并设置事件回调函数。

TcpConnection::connectEstablished函数最主要的是通知Channel自己开始关心IO读取事件：

    void TcpConnection::connectEstablished()
    {
        ...
        channel_->enableReading();

这是自此我们看到的第二个Channel::enableXXX接口，这些接口是如何实现关心IO事件的呢？这个后面讲到。

muduo的数据发送都是通过TcpConnection::send完成，这个就是一般网络库中在不使用OS的异步IO情况下的实现：缓存应用层传递过来的数据，在IO设备可写的情况下尽量写入数据。这个主要实现在TcpConnection::sendInLoop中。

    TcpConnection::sendInLoop(....) {
        ...
        // if no thing in output queue, try writing directly
        if (!channel_->isWriting() && outputBuffer_.readableBytes() == 0)  // 设备可写且没有缓存时立即写入
        { 
            nwrote = sockets::write(channel_->fd(), data, len);
        }
        ...
        // 否则加入数据到缓存，等待IO可写时再写
        outputBuffer_.append(static_cast<const char*>(data)+nwrote, remaining);
        if (!channel_->isWriting())
        {
            // 注册关心IO写事件，Poller就会对写做检测
            channel_->enableWriting();
        }
        ...     
    }

当IO可写时，Channel就会回调TcpConnection::handleWrite（构造函数中注册）

    void TcpConnection::handleWrite()
    {
        ...
        if (channel_->isWriting())
        {
            ssize_t n = sockets::write(channel_->fd(),
                               outputBuffer_.peek(),
                               outputBuffer_.readableBytes());

服务器端的数据收发同客户端机制一致，不同的是连接(TcpConnection)的建立方式不同。

服务器接收连接

服务器接收连接的实现在一个网络库中比较重要。muduo中通过Acceptor类来接收连接。在TcpClient中，其Connector通过一个关心Channel可写的事件来通过连接已建立；在Acceptor中则是通过一个Channel可读的事件来表示有新的连接到来：

    Acceptor::Acceptor(....) {
        ...
        acceptChannel_.setReadCallback(
            boost::bind(&Acceptor::handleRead, this));
        ... 
    }

    void Acceptor::handleRead()
    {
        ...
        int connfd = acceptSocket_.accept(&peerAddr); // 接收连接获得一个新的socket
        if (connfd >= 0)
        {
            ...
            newConnectionCallback_(connfd, peerAddr); // 回调到TcpServer::newConnection

TcpServer::newConnection中建立一个TcpConnection，并将其附加到一个EventLoopThread中，简单来说就是给其配置一个线程：

    void TcpServer::newConnection(int sockfd, const InetAddress& peerAddr)
    {
        ...
        EventLoop* ioLoop = threadPool_->getNextLoop();
        TcpConnectionPtr conn(new TcpConnection(ioLoop,
                                                connName,
                                                sockfd,
                                                localAddr,
                                                peerAddr));
        connections_[connName] = conn;
        ...
        ioLoop->runInLoop(boost::bind(&TcpConnection::connectEstablished, conn));

IO的驱动

之前提到，一旦要关心某IO事件了，就调用Channel::enableXXX，这个如何实现的呢？

    class Channel {
        ...
        void enableReading() { events_ |= kReadEvent; update(); }
        void enableWriting() { events_ |= kWriteEvent; update(); }
       
    void Channel::update()
    {
        loop_->updateChannel(this);
    }

    void EventLoop::updateChannel(Channel* channel)
    {
        ...
        poller_->updateChannel(channel);
    }

最终调用到Poller::upateChannel。muduo中有两个Poller的实现，分别是Poll和EPoll，可以选择简单的Poll来看：

    void PollPoller::updateChannel(Channel* channel)
    {
      ...
      if (channel->index() < 0)
      {
        // a new one, add to pollfds_
        assert(channels_.find(channel->fd()) == channels_.end());
        struct pollfd pfd;
        pfd.fd = channel->fd();
        pfd.events = static_cast<short>(channel->events()); // 也就是Channel::enableXXX操作的那个events_
        pfd.revents = 0;
        pollfds_.push_back(pfd); // 加入一个新的pollfd
        int idx = static_cast<int>(pollfds_.size())-1;
        channel->set_index(idx);
        channels_[pfd.fd] = channel;

可见Poller就是把Channel关心的IO事件转换为OS提供的IO模型数据结构上。通过查看关键的pollfds_的使用，可以发现其主要是在Poller::poll接口里。这个接口会在EventLoop的主循环中不断调用：

    void EventLoop::loop()
    {
      ...
      while (!quit_)
      {
        activeChannels_.clear();
        pollReturnTime_ = poller_->poll(kPollTimeMs, &activeChannels_);
        ...
        for (ChannelList::iterator it = activeChannels_.begin();
            it != activeChannels_.end(); ++it)
        {
          currentActiveChannel_ = *it;
          currentActiveChannel_->handleEvent(pollReturnTime_); // 获得IO事件，通知各注册回调
        }

整个流程可总结为：各Channel内部会把自己关心的事件告诉给Poller，Poller由EventLoop驱动检测IO，然后返回哪些Channel发生了事件，EventLoop再驱动这些Channel调用各注册回调。

从这个过程中可以看出，EventLoop就是一个事件产生器。

线程模型

在muduo的服务器中，muduo的线程模型是怎样的呢？它如何通过线程来支撑高并发呢？其实很简单，它为每一个线程配置了一个EventLoop，这个线程同时被附加了若干个网络连接，这个EventLoop服务于这些网络连接，为这些连接收集并派发IO事件。

回到TcpServer::newConnection中：

    void TcpServer::newConnection(int sockfd, const InetAddress& peerAddr)
    {
      ...
      EventLoop* ioLoop = threadPool_->getNextLoop();
      ...
      TcpConnectionPtr conn(new TcpConnection(ioLoop, // 使用这个选择到的线程中的EventLoop
                                              connName,
                                              sockfd,
                                              localAddr,
                                              peerAddr));
      ...
      ioLoop->runInLoop(boost::bind(&TcpConnection::connectEstablished, conn));

注意TcpConnection::connectEstablished是如何通过Channel注册关心的IO事件到ioLoop的。

极端来说，muduo的每一个连接线程可以只为一个网络连接服务，这就有点类似于thread per connection模型了。

网络模型

传说中的Reactor模式，以及one loop per thread，基于EventLoop的作用，以及线程池与TcpConnection的关系，可以醍醐灌顶般理解以下这张muduo的网络模型图了：

总结

本文主要对muduo的主要结构及主要机制的实现做了描述，其他如Buffer的实现、定时器的实现大家都可以自行研究。muduo的源码很清晰，通过源码及配合陈硕博客上的内容可以学到一些网络编程方面的经验。

Kevin Lynx 2014-05-04 18:22 发表评论

记一次堆栈平衡错误

Kevin Lynx — Thu, 15 Aug 2013 15:01:00 GMT

最近在一个使用Visual Studio开发的C++程序中，出现了如下错误：

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

这个错误主要指的就是函数调用堆栈不平衡。在C/C++程序中，调用一个函数前会保存当前堆栈信息，目标函数返回后会把堆栈恢复到调用前的状态。函数的参数、局部变量会影响堆栈。而函数堆栈不平衡，一般是因为函数调用方式和目标函数定义方式不一致导致，例如：

void __stdcall func(int a) {
}

int main(int argc, char* argv[]) {
    typedef void (*funcptr)(int);
    funcptr ptr = (funcptr) func;
    ptr(1); // 返回后导致堆栈不平衡
    return 0;
}

__stdcall修饰的函数，其函数参数的出栈由被调用者自己完成，而__cdecl，也就是C/C++函数的默认调用约定，则是调用者完成参数出栈。

Visual Studio在debug模式下会在我们的代码中加入不少检查代码，例如以上代码对应的汇编中，就会增加一个检查堆栈是否平衡的函数调用，当出现问题时，就会出现提示Run-Time Check Failure...这样的错误对话框：

call dword ptr [ptr]  ; ptr(1)
add  esp,4  ; cdecl方式，调用者清除参数
cmp  esi,esp  
call @ILT+1345(__RTC_CheckEsp) (0B01546h) ; 检查堆栈是否平衡

但是我们的程序不是这种低级错误。我们调用的函数是放在dll中的，调用约定显示定义为__stdcall，函数声明和实现一致。大致的结构如下：

IParser *parser = CreateParser();
parser->Begin();
...
...
parser->End();
parser->Release(); // 返回后导致堆栈不平衡

IParser的实现在一个dll里，这反而是一个误导人的信息。parser->Release返回后，堆栈不平衡，并且仅仅少了一个字节。一个字节怎么来的？

解决这个问题主要的手段就是跟反汇编，在关键位置查看寄存器和堆栈的内容。编译器生成的代码是正确的，而我们自己的代码乍看上去也没问题。最后甚至使用最傻逼的调试手段–逐行语句注释查错。

具体查错过程就不细说了。解决问题往往需要更多的冷静，和清晰的思路。最终我使用的方法是，在进入Release之前记录堆栈指针的值，堆栈指针的值会被压入堆栈，以在函数返回后从堆栈弹出，恢复堆栈指针。Release的实现很简单，就是删除一个Parser这个对象，但这个对象的析构会导致很多其他对象被析构。我就逐层地检查，是在哪个函数里改变了堆栈里的内容。

理论上，函数本身是操作不到调用者的堆栈的。而现在看来，确实是被调用函数，也就是Release改写了调用者的堆栈内容。要改变堆栈的内容，只有通过局部变量的地址才能做到。

最终，我发现在调用完以下函数后，我跟踪的堆栈地址内容发生了改变：

call llvm::RefCountedBase::Release (10331117h)

因为注意到TargetOptions这个字眼，想起了在parser->Begin里有涉及到这个类的使用，类似于：

TargetOptions TO;
...
TargetInfo *TI = TargetInfo::CreateTargetInfo(m_inst.getDiagnostics(), TO);

这部分初始化代码，是直接从网上复制的，因为并不影响主要逻辑，所以从来没对这块代码深究。查看CreateTargetInfo的源码，发现这个函数将TO这个局部变量的地址保存了下来。

而在Release中，则会对这个保存的临时变量进行删除操作，形如：

void Delete() const {
  assert (ref_cnt > 0 && "Reference count is already zero.");
  if (--ref_cnt == 0) delete static_cast<const Derived*>(this);
}

但是，问题并不在于对一个局部变量地址进行delete，delete在调试模式下是做了内存检测的，那会导致一种断言。

TargetOptions包含了ref_cnt这个成员。当出了Begin作用域后，parser保存的TargetOptions的地址，指向的内容（堆栈）发生了改变，也就是ref_cnt这个成员变量的值不再正常。由于一些巧合，主要是代码中各个局部变量、函数调用顺序、函数参数个数（曾尝试去除Begin的参数，可以避免错误提示），导致在调用Release前堆栈指针恰好等于之前保存的TargetOptions的地址。注意，之前保存的TargetOptions的地址，和调用Release前的堆栈指针值相同了。

而在TargetOptions的Delete函数中，进行了--ref_cnt，这个变量是TargetOptions的第一个成员，它的减1，也就导致了堆栈内容的改变。

至此，整个来龙去脉算是摸清。

Kevin Lynx 2013-08-15 23:01 发表评论

分布式程序开发平台ICE概览

Kevin Lynx — Fri, 15 Feb 2013 07:24:00 GMT

本文基于ICE Manual及相关文档就ICE的一些主要特性做一个概览，它不是一个tutorial，不是一个guid，更不是manual。

概览

ICE，Internet Communications Engine，按照官方介绍，是一个支持C++、.Net、Java、Python、Objective-C、Ruby、PHP及ActionScript等语言的分布式程序开发平台。按照我的理解，简单来说它是一个核心功能包装RPC的库。要把这个RPC包装得漂亮，自然而然，对于使用者而言，调用一个远端的接口和调用一个本地的接口没有什么区别，例如：

    Object *obj = xxx
    obj->sayHello();

ICE包装sayHello接口，当应用层调用该接口时，ICE发送调用请求到远端服务器，接收返回结果并返回给应用层。ICE在接口提供方面，做到了这一点。

以下，我将逐个给出ICE中的一些工具、组件、特性说明，以展示它作为一个分布式程序开发平台所拥有的能力。到目前为止，所有这些信息均来自于ICE相关文档，总结出来权当为自己服务。

Slice

Slice(Specification Language for Ice)是ICE定义的一种中间语言，其语法类似于C++。对于一个RPC过程而言，例如上面调用远端的sayHello接口，其主要涉及到调用这个接口的参数和返回值传递，当然接口本身的传递不在话下，ICE为了包装这个过程，其使用了这样一种方式：使用者使用Slice语言描述RPC过程中调用的接口，例如该接口属于哪个类，该接口有哪些参数哪些返回值；然后使用者使用ICE提供的Slice编译器（实际上是一个语言翻译程序）将Slice源码翻译成目标语言。而这个目标语言，则是使用者开发应用程序的开发语言，即上文提到的C++、.Net、Java等。

这些翻译出来的目标代码，就封装了sayHello底层实现的一切细节。当然事情没有这么简单，但我们目前只需关注简单的这一部分。ICE之所以支持那么多种开发语言，正是Slice立下的功劳。Slice语言本身的语言特性，实际上受限于目标语言的语言特性，例如Slice支持异常，恰是因为Slice转换的所有语言都包含异常这个语法特性。

Slice还有一个重要特性，在于一份Slice源码被翻译出来的目标代码，一般情况是被服务器和客户端同时使用。

开发步骤

使用ICE开发应用程序，其步骤遵循：

编写Slice，说明整个RPC中涉及到的接口调用，编译它
基于Slice目标代码和ICE库编写Server
基于Slice目标带啊和ICE库编写Client

一个例子

有必要展示一个例子，以获得使用ICE开发应用程序的感性认识。这个例子是一个简单的hello world程序，客户端让服务器打印一个字符串。

编写Slice

    // Printer.ice，Slice源码后缀为ice
    module Demo {
        interface Printer {
            void printString(string s);
        };
    };

使用ICE提供的程序翻译为C++代码：

    $ slice2cpp Printer.ice

得到Printer.cpp和Printer.h。Slice翻译出来的目标代码除了封装RPC交互的一些细节外，最重要的，因为本身Slice文件其实是定义接口，但接口的实现，则需要应用层来做。

服务器端使用生成的Printer.cpp/.h，并实现Printer接口

    // 翻译出来的Printer.h中有对应于Slice中定义的Printer类，及需要实现的printString接口
    class PrinterI : public Printer {
    public:
        virtual void printString(const string& s, const Ice::Current&) {
            count << s << endl;
        }
    };

客户端使用生成的Printer.cpp/.h，通过ICE获得一个Printer对象，然后调用其printString接口

    // don't care about this
    PrinterPrx printer = PrinterPrx::checkedCast(base);
    printer->printString("Hello World!");

使用ICE开发应用程序，整体过程即为以上展示。

概念

ICE包含了很多概念，作为一个开发平台而言，有其专有术语一点不过分，熟悉这些概念可以更容易学习ICE。这里罗列一些关键概念。

服务器端和客户端

ICE中的服务器端和客户端和一般网络程序中的概念不太一样。在若干个交互的网络程序中，我们都很好理解这样一种现象：某个程序有多个角色，它可能是作为A程序的服务器端，也可能是作为B程序的客户端。ICE中的服务器和客户端角色更容易变换。

以Printer例子为例，如果我们的printString接口有一个回调函数参数（这在ICE中很常见），服务器实现printString时，当其打印出字符串后，需通过该回调函数通知客户端。这样的回调机制在ICE的实现中，会创建一个新的网络连接，而此时，这个原有的服务器端就变成了原有客户端的客户。当然，你也可以避免这样的情况出现。

ICE Objects/Object Adapter/Facet

对于Printer例子，一个Printer对象可以被看作是一个ICE Objects。Object可以说是服务器端提供给客户端的接口。所以在服务器端通常会创建出很多个Object。服务器端使用Object Adapter对象去保存这些Object。例如，一个典型的ICE对象在初始化时可能包含以下代码：

    // 创建一个Object Adapter
    Ice::ObjectAdapterPtr adapter = communicator()->createObjectAdapter("Hello");
    // 创建一个Object，形如Printer
    Demo::HelloPtr hello = new HelloI;
    // 将Object加入到Object Adapter
    adapter->add(hello, communicator()->stringToIdentity("hello"));

Facet是Object的一部分，或者说Object是Facet的一个集合，摘Ice manual中的一句话：

An Ice object is actually a collection of sub-objects known as facets whose types are not necessarily related.

Proxy

Proxy是ICE客户端里的概念。客户端通过Proxy访问服务器端上的Object，通过Proxy调用服务器端Object上提供的接口。在客户端上一般有类似以下代码：

    Ice::ObjectPrx base = ic->stringToProxy("SimplePrinter:default -p 10000");
    // Printer Proxy
    PrinterPrx printer = PrinterPrx::checkedCast(base);
    printer->printString("Hello World!");

Proxy又分为几种，包括：

Direct Proxy

Direct Proxy，这里的direct意指这个proxy访问的object时，是否携带了地址(EndPoint)信息，例如上面例子中SimplePrinter:default -p 10000就是一个地址。

Indirect Proxy

Indirect Proxy相对Direct Proxy而言，其没有具体的地址，仅仅是一个符号。通常包含两种形式：

SimplePrinter
SimplePrinter@PrinterAdapter

为了获取真正的地址，客户端需要一个定位服务（location service）来获取这个符号对应的地址。ICE中提供了一些默认的服务程序，IceGrid就是其中之一，而IceGrid的作用就包括定位具体的地址，即翻译符号地址到具体的地址。

这里Indirect Proxy可以看作一个域名，而Direct Proxy可以看作是IP地址。Indirect Proxy使用时，就需要借助DNS翻译得到域名对应的IP地址。

Fixed Proxy

由于Proxy是用于与服务器端的Object通信的，客户端借助Proxy来访问服务器端的Object，所以Proxy通常都会对应一个真实的网络连接。在ICE中，一般的Proxy于网络连接(Connection)实际上是没有太大关联的。一个Proxy可以没有Connection，也可以在建立这个Connection后又断开之。但是，ICE提供了一种特殊的Proxy，Fixed Proxy，这种Proxy紧密地与一个Connection绑定在一起，其生命周期被强制关联起来。

关于Fixed Proxy可以参看ICE Manual Connection Management。

其他

Asynchronous Method Invocation，对于客户端而言，用于表示某个服务器端接口是异步操作，需在Slice中使用metadata来修饰这个接口，例如：

    ["ami"]  void sayHello(int delay)

Asynchronous method dispatch，这个针对于服务器端，同样表示这个接口是异步操作，需在Slice中使用metadata来修饰这个接口：

    ["ami", "amd"]  void sayHello(int delay)

通常对于这种异步接口而言，都需要使用Slice metadata ami和amd同时修饰。

idempotent

idempotent是Slice中的概念，同const一样用于修饰某个接口的特性。idempotent表示该接口无论调用多少次，其执行结果都是相同的，例如一般的get类接口。

batched invocation

客户端调用服务器端的接口这个动作称为invocation。就像网络层的数据缓存一样，ICE对于接口调用也可能暂时缓存，当多个提交请求缓存起来后，然后调用刷新接口全部刷新到服务器端，则称为batched invocation。

服务

ICE除了提供一个库之外，还提供了一些应用程序。这些应用程序本身也是一些服务器，提供了一些方便的功能方便我们开发分布式程序。

Freeze

Freeze用于将Slice对象持久化到数据库中，按照Manual里的说法，它应该是一个编译器，可以生成一些持久化操作的代码。Freeze持久化对象时使用的数据库是Berkeley DB。

Ice has a built-in object persistence service, known as Freeze. Freeze makes it easy to store object state in a database: you define the state stored by your objects in Slice, and the Freeze compiler generates code that stores and retrieves object state to and from a database. Freeze uses Berkeley DB as its database.

FreezeScript有点类似于Rails中的数据库操作工具，可用于操作持久化到数据库中的对象数据。

Ice also offers a tool set collectively called FreezeScript that makes it easier to maintain databases and to migrate the contents of existing databases to a new schema if the type definitions of objects change.

IceBox

IceBox可用于管理服务器中的动态组件。这些动态组件本质上也是提供服务的ICE程序。在形式上，这些组件可以是动态连接库。

IceBox is a simple application server that can orchestrate the starting and stopping of a number of application components. Application components can be deployed as a dynamic library instead of as a process.

IceGrid

IceGrid相当于一个DNS解析服务，可以让服务器不用配置EndPoint，客户端也不用指定服务器的EndPoint，以方便大量的服务器部署。在一般的应用中，我们需要为ICE服务器指定绑定的网络地址（IP和端口），同时也需要为客户端指定服务器端的地址信息。当服务增加到一定数量时，就会存在管理上和配置上的麻烦。而IceGrid则是用于避免这种麻烦，将服务器端和客户端上的地址信息通过一个符号代替，就像我们把Internet上的服务器使用域名来标识一样。

但IceGrid的作用不仅如此，通过配合部署一系列称为IceGrid Node的程序，IceGrid还可以管理各个服务器的启动、关闭、宕机重启等，其中甚至包括负载均衡。

IceGrid provides a facility to activate servers on demand, when a client first invokes an operation. Server activation is taken care of by IceGrid nodes. You must run an IceGrid node on each machine on which you want IceGrid to start servers on demand.

简要介绍可以参看ICE Manual Teach Yourself IceGrid in 10 minutes

Glacier2

Glacier2 is a lightweight firewall traversal solution for Ice applications.

按我的理解，Glacier2就像一个网关服务器。它被部署在服务器和客户端之间，我们的服务器群部署在内网，外网不可访问，然后通过Glacier2，外部网络的客户端就可以访问内网的服务器群提供的服务。

对于服务器的开发而言，使用Glacier2，服务器端不需要做任何改动。客户端需要配置Glacier2服务的地址信息，也需要配置要使用服务器的地址信息。Glacier2通过客户端欲访问的服务器地址，在内网定位到真实的服务器，并转发请求提供服务。

Glacier2支持验证客户端，从这一点看来，它又有点像一个验证服务器。通过验证客户端，以提供被正确授权的客户端以完整服务。

Glacier2的工作过程可以描述为：

When a client invokes an operation on a routed proxy, the client connects to one of Glacier2’s client endpoints and sends the request as if Glacier2 is the server. Glacier2 then establishes an outgoing connection to the client’s intended server in the private network, forwards the request to that server, and returns the reply (if any) to the client. Glacier2 is essentially acting as a local client on behalf of the remote client.

一个Glacier2可服务于若干个客户端和服务器。

详细参看ICE Manual Glacier2

管理

ICE服务器可以提供给外部一定的管理功能，包括：关闭服务器、读取服务器配置。这个功能是通过操作Ice.Admin这个Ice Object来实现的。这个Object包含两个Facet：Process和Property，分别对应于关闭服务器和读取服务器配置功能。

对于需要管理服务器的客户端而言，可以大致通过如下代码来完成：

    // 可以通过communicator来获取这个admin object
    Ice::ObjectPrx adminObj = ...;
    // 获取admin object里的property facet
    Ice::PropertiesAdminPrx propAdmin = Ice::PropertiesAdminPrx::checkedCast(adminObj, "Properties");
    Ice::PropertyDict props = propAdmin->getPropertiesForPrefix("");

详细参看ICE Manual Administrative Facility

连接管理

前已述及，ICE中的网络连接隐藏于Proxy之下。Proxy有两个接口可以获取这个连接对象：

    ice_getConnection
    ice_getCachedConnection

例如：

    HelloPrx hello = HelloPrx::uncheckedCast(communicator->stringToProxy("hello:tcp -h remote.host.com -p 10000"));
    ConnectionPtr conn = hello->ice_getConnection();

ICE隐藏了网络连接的细节。当ICE发现需要建立连接时才会去建立，例如以上例子中当获得一个Proxy时（这里是HelloPrx），ICE并不建立网络连接，当某个时刻通过该Proxy调用服务器端的某个接口时，ICE发现对应的网络连接没有建立，则发起网络连接。

以上例子在获取Proxy时，使用了uncheckCast，关于checkedCast和uncheckedCast，也影响着网络连接的建立逻辑：

On the other hand, if the code were to use a checkedCast instead, then connection establishment would take place as part of the checkedCast, because a checked cast requires a remote call to determine whether the target object supports the specified interface.

关于连接管理，ICE使用了一个称为ACM的机制，即Active connection management。当某个连接非active一段时间后，ICE就会主动关闭此连接。应用层当然可以控制这个行为。

详细参看ICE Manual Connection Management

Kevin Lynx 2013-02-15 15:24 发表评论

使用Clang实现C语言编程规范检查

Kevin Lynx — Tue, 12 Feb 2013 13:53:00 GMT

概述

Clang是LLVM编译器工具集的前端部分，也就是涵盖词法分析、语法语义分析的部分。而LLVM是Apple在Mac OS上用于替代GCC工具集的编译器软件集合。Clang支持类C语言的语言，例如C、C++、Objective C。Clang的与众不同在于其模块化的设计，使其不仅实现编译器前端部分，并且包装成库的形式提供给上层应用。使用Clang可以做诸如语法高亮、语法检查、编程规范检查方面的工作，当然也可以作为你自己的编译器前端。

编程规范一般包含编码格式和语义规范两部分。编码格式用于约定代码的排版、符号命名等；而语义规范则用于约定诸如类型匹配、表达式复杂度等，例如不允许对常数做逻辑运算、检查变量使用前是否被赋值等。本文描述的主要是基于语义方面的检查，其经验来自于最近做的一个检查工具，该工具实现了超过130条的规范。这份规范部分规则来自于MISRA C

编程模式

编译器前端部分主要是输出代码对应的抽象语法树(AST)。Clang提供给上层的接口也主要是围绕语法树来做操作。通过google一些Clang的资料，你可能会如我当初一样对该如何正确地使用Clang心存疑惑。我最后使用的方式是基于RecursiveASTVisitor。这是一种类似回调的使用机制，通过提供特定语法树节点的接口，Clang在遍历语法树的时候，在遇到该节点时，就会调用到上层代码。不能说这是最好的方式，但起码它可以工作。基于RecursiveASTVisitor使用Clang，程序主体框架大致为：

// 编写你感兴趣的语法树节点访问接口，例如该例子中提供了函数调用语句和goto语句的节点访问接口
class MyASTVisitor : public RecursiveASTVisitor<MyASTVisitor> {
public:
    bool VisitCallExpr(CallExpr *expr);

    bool VisitGotoStmt(GotoStmt *stmt);
    ...
};

class MyASTConsumer : public ASTConsumer {
public:
    virtual bool HandleTopLevelDecl(DeclGroupRef DR) {
        for (DeclGroupRef::iterator b = DR.begin(), e = DR.end(); b != e; ++b) {
            Visitor.TraverseDecl(*b);
        }
        return true;
    } 
    
private:
    MyASTVisitor Visitor;
};

int main(int argc, char **argv) {
    CompilerInstance inst;
    Rewriter writer;
    inst.createFileManager();
    inst.createSourceManager(inst.getFileManager());
    inst.createPreprocessor();
    inst.createASTContext();
    writer.setSourceMgr(inst.getSourceManager(), inst.getLangOpts());
    ... // 其他初始化CompilerInstance的代码
  
    const FileEntry *fileIn = fileMgr.getFile(argv[1]);
    sourceMgr.createMainFileID(fileIn);
    inst.getDiagnosticClient().BeginSourceFile(inst.getLangOpts(), &inst.getPreprocessor());
    MyASTConsumer consumer(writer);
    ParseAST(inst.getPreprocessor(), &consumer, inst.getASTContext());
    inst.getDiagnosticClient().EndSourceFile();
    return 0;
}

以上代码中，ParseAST为Clang开始分析代码的主入口，其中提供了一个ASTConsumer。每次分析到一个顶层定义时(Top level decl)就会回调MyASTConsumer::HandleTopLevelDecl，该函数的实现里调用MyASTVisitor开始递归访问该节点。这里的decl实际上包含定义。

这里使用Clang的方式来源于Basic source-to-source transformation with Clang。

语法树

Clang中视所有代码单元为语句(statement)，Clang中使用类Stmt来代表statement。Clang构造出来的语法树，其节点类型就是Stmt。针对不同类型的语句，Clang有对应的Stmt子类，例如GotoStmt。Clang中的表达式也被视为语句，Clang使用Expr类来表示表达式，而Expr本身就派生于Stmt。

每个语法树节点都会有一个子节点列表，在Clang中一般可以使用如下语句遍历一个节点的子节点：

for (Stmt::child_iterator it = stmt->child_begin(); it != stmt->child_end(); ++it) {
    Stmt *child = *it;
}

但遗憾的是，无法从一个语法树节点获取其父节点，这将给我们的规范检测工具的实现带来一些麻烦。

TraverseXXXStmt

在自己实现的Visitor中（例如MyASTVisitor），除了可以提供VisitXXXStmt系列接口去访问某类型的语法树节点外，还可以提供TraverseXXXStmt系列接口。Traverse系列的接口包装对应的Visit接口，即他们的关系大致为：

bool TraverseGotoStmt(GotoStmt *s) {
    VisitGotoStmt(s);
    return true;
}

例如对于GotoStmt节点而言，Clang会先调用TraverseGotoStmt，在TraverseGotoStmt的实现中才会调用VisitGotoStmt。利用Traverse和Visit之间的调用关系，我们可以解决一些因为不能访问某节点父节点而出现的问题。例如，我们需要限制逗号表达式的使用，在任何地方一旦检测到逗号表达式的出现，都给予警告，除非这个逗号表达式出现在for语句中，例如：

a = (a = 1, b = 2); /* 违反规范，非法 */
for (a = 1, b = 2; a < 2; ++a) /* 合法 */

逗号表达式对应的访问接口为VisitBinComma，所以我们只需要提供该接口的实现即可：

class MyASTVisitor : public RecursiveASTVisitor<MyASTVisitor> {
public:
    ...
    bool VisitBinComma(BinaryOperator *stmt) {
        /* 报告错误 */
        return true;
    }
    ...
};

（注：BinaryOperator用于表示二目运算表达式，例如a + b，逗号表达式也是二目表达式）

但在循环中出现的逗号表达式也会调用到VisitBinComma。为了有效区分该逗号表达式是否出现在for语句中，我们可以期望获取该逗号表达式的父节点，并检查该父节点是否为for语句。但Clang并没有提供这样的能力，我想很大一部分原因在于臆测语法树（抽象语法树）节点的组织结构（父节点、兄弟节点）本身就不是一个确定的事。

这里的解决办法是通过提供TraverseForStmt，以在进入for语句前得到一个标识：

class MyASTVisitor : public RecursiveASTVisitor<MyASTVisitor> {
public:
    ...
    // 这个函数的实现可以参考RecursiveASTVisitor的默认实现，我们唯一要做的就是在for语句的头那设定一个标志m_inForLine
    bool TraverseForStmt(ForStmt *s) {
        if (!WalkUpFromForStmt(s))
            return false;
        m_inForLine = true;
        for (Stmt::child_range range = s->children(); range; ++range) {
            if (*range == s->getBody())
                m_inForLine = false;
            TraverseStmt(*range);
        }
        return true;
    }

    bool VisitBinComma(BinaryOperator *stmt) {
        if (!m_inForLine) {
            /* 报告错误 */
        }
        return true;
    }
    ...
};

（注：严格来说，我们必须检查逗号表达式是出现在for语句的头中，而不包括for语句循环体）

类型信息

对于表达式(Expr)而言，都有一个类型信息。Clang直接用于表示类型的类是QualType，实际上这个类只是一个接口包装。这些类型信息可以用于很多类型相关的编程规范检查。例如不允许定义超过2级的指针(例如int ***p)：

bool MyASTVisitor::VisitVarDecl(VarDecl *decl) { // 当发现变量定义时该接口被调用
    QualType t = decl->getType(); // 取得该变量的类型
    int pdepth = 0;
    // check pointer level
    for ( ; t->isPointerType(); t = t->getPointeeType()) { // 如果是指针类型就获取其指向类型(PointeeType)
        ++pdepth;
    }
    if (pdepth >= 3)
        /* 报告错误 */
}

可以直接调用Expr::getType接口，用于获取指定表达式最终的类型，基于此我们可以检查复杂表达式中的类型转换，例如：

float f = 2.0f;
double d = 1.0;
f = d * f; /* 检查此表达式 */

对以上表达式的检查有很多方法，你可以实现MyASTVisitor::VisitBinaryOperator（只要是二目运算符都会调用），或者MyASTVisitor::VisitBinAssign（赋值运算=调用）。无论哪种方式，我们都可以提供一个递归检查两个表达式类型是否相同的接口：

bool HasDiffType(BinaryOperator *stmt) {
    Expr *lhs = stmt->getLHS()->IgnoreImpCasts(); // 忽略隐式转换
    Expr *rhs = stmt->getRHS()->IgnoreImpCasts();
    if (lhs->getType() == rhs->getType())) {
        if (isa<BinaryOperator>(lhs) && HasDiffType(cast<BinaryOperator>(lhs)))
            return true;
        if (isa<BinaryOperator>(rhs) && HasDiffType(cast<BinaryOperator>(rhs)))
            return true;
        return false;
    }
    return true;
}

（注：此函数只是简单实现，未考虑类型修饰符之类的问题）

该函数获得二目运算表达式的两个子表达式，然后递归检测这两个表达式的类型是否相同。

Expr类提供了更多方便的类型相关的接口，例如判定该表达式是否为常数，是否是布尔表达式，甚至在某些情况下可以直接计算得到值。例如我们可以检查明显的死循环:

while (1) { }

可以使用：

ASTContext &context = inst.GetASTContext();
bool result;
// 假设stmt为WhileStmt
if (stmt->getCond()->EvaluateAsBooleanCondition(result, context)) {
    if (result) 
        /* 死循环 */

符号表

符号表这个概念比较广义，这里我仅指的是用于保存类型和变量信息的表。Clang中没有显示的符号表数据结构，但每一个定义都有一个DeclContext，DeclContext用于描述一个定义的上下文环境。有一个特殊的DeclContext被称为translation unit decl，其实也就是全局环境。利用这个translation unit decl，我们可以获取一些全局符号，例如全局变量、全局类型：

// 获取全局作用域里指定名字的符号列表
DeclContext::lookup_result GetGlobalDecl(const std::string &name) {
    ASTContext &context = CompilerInst::getSingleton().GetASTContext();
    DeclContext *tcxt = context.getTranslationUnitDecl();
    IdentifierInfo &id = context.Idents.get(name);
    return tcxt->lookup(DeclarationName(&id));
}

// 可以根据GetGlobalDecl的返回结果，检查该列表里是否有特定的定义，例如函数定义、类型定义等
bool HasSpecDecl(DeclContext::lookup_result ret, Decl::Kind kind) {
    for (size_t i = 0; i < ret.size(); ++i) {
        NamedDecl *decl = ret[i];
        if (decl->getKind() == kind) {
            return true;
        }
    }
    return false;
}

有了以上两个函数，我们要检测全局作用域里是否有名为”var”的变量定义，就可以：

HasSpecDecl(GetGlobalDecl("var"), Decl::Var);

每一个Decl都有对应的DeclContext，要检查相同作用域是否包含相同名字的符号，其处理方式和全局的方式有点不一样：

// 检查在ctx中是否有与decl同名的符号定义
bool HasSymbolInContext(const NamedDecl *decl, const DeclContext *ctx) {
    for (DeclContext::decl_iterator it = ctx->decls_begin(); it != ctx->decls_end(); ++it) {
        Decl *d = *it;
        if (d != decl && isa<NamedDecl>(d) && 
            cast<NamedDecl>(d)->getNameAsString() == decl->getNameAsString())
            return true;
    }
    return false;
}

bool HasSymbolInContext(const NamedDecl *decl) {
    return HasSymbolInContext(decl, decl->getDeclContext());
}

可以看出，这里检查相同作用域的方式是遍历上下文环境中的所有符号，但对于全局作用域却是直接查找。对于DeclContext的详细信息我也不甚明了，只能算凑合使用。实际上，这里使用“作用域”一词并不准确，在C语言中的作用域概念，和这里的context概念在Clang中并非等同。

如果要检查嵌套作用域里不能定义相同名字的变量，例如：

int var;
{
    int var;
}

通过Clang现有的API是无法实现的。因为Clang给上层的语法树结构中，并不包含作用域信息（在Clang的实现中，用于语义分析的类Sema实际上有作用域的处理）。当然，为了实现这个检测，我们可以手动构建作用域信息（通过TraverseCompoundStmt）。

宏

宏的处理属于预处理阶段，并不涵盖在语法分析阶段，所以通过Clang的语法树相关接口是无法处理的。跟宏相关的接口，都是通过Clang的Preprocessor相关接口。Clang为此提供了相应的处理机制，上层需要往Preprocessor对象中添加回调对象，例如：

class MyPPCallback : public PPCallbacks {
public:
    // 处理#include
    virtual void InclusionDirective(SourceLocation HashLoc, const Token &IncludeTok,
        StringRef FileName, bool IsAngled, CharSourceRange FilenameRange,
        const FileEntry *File, StringRef SearchPath, StringRef RelativePath, const Module *Imported) {
    }

    // 处理#define
    virtual void MacroDefined(const Token &MacroNameTok, const MacroInfo *MI) {
    }

    virtual void MacroUndefined(const Token &MacroNameTok, const MacroInfo *MI) {
    } 
}

inst.getPreprocessor().addPPCallbacks(new MyPPCallback());

即，通过实现PPCallbacks中对应的接口，就可以获得处理宏的通知。

Clang使用MacroInfo去表示一个宏。MacroInfo将宏体以一堆token来保存，例如我们要检测宏体中使用##和#的情况，则只能遍历这些tokens:

// 分别记录#和##在宏体中使用的数量
int hash = 0, hashhash = 0;
for (MacroInfo::tokens_iterator it = MI->tokens_begin(); it != MI->tokens_end(); ++it) {
    const Token &token = *it;
    hash += (token.getKind() == tok::hash ? 1 : 0);
    hashhash += (token.getKind() == tok::hashhash ? 1 : 0);
}

其他

在我们所支持的编程规范中，有些规范是难以支持的，因此我使用了一些蹩脚的方式来实现。

手工解析

在针对函数的参数定义方面，我们支持的规范要求不能定义参数为空的函数，如果该函数没有参数，则必须以void显示标识，例如：

int func(); /* 非法 */
int func(void); /* 合法 */

对于Clang而言，函数定义（或声明）使用的是FunctionDecl，而Clang记录的信息仅包括该函数是否有参数，参数个数是多少，并不记录当其参数个数为0时是否使用void来声明（记录下来没多大意义）。解决这个问题的办法，可以通过SourceLocation获取到对应源代码中的文本内容，然后对此文本内容做手工分析即可。

（注：SourceLocation是Clang中用于表示源代码位置的类，包括行号和列号，所有Stmt都会包含此信息）

通过SourceLocation获取对应源码的内容：

std::pair<FileID, unsigned> locInfo = SM.getDecomposedLoc(loc);
bool invalidTemp = false;
llvm::StringRef file = SM.getBufferData(locInfo.first, &invalidTemp);
if (invalidTemp)
    return false;
// tokenBegin即为loc对应源码内容的起始点
const char *tokenBegin = file.data() + locInfo.second;

要手工分析这些内容实际上还是有点繁杂，为此我们可以直接使用Clang中词法分析相关的组件来完成这件事：

Lexer *lexer = new Lexer(SM.getLocForStartOfFile(locInfo.first), opts, file.begin(), tokenBegin, file.end());
Token tok;
lexer->Lex(tok); // 取得第一个tok，反复调用可以获取一段token流

Diagnostic

Clang中用Diagnostic来进行编译错误的提示。每一个编译错误（警告、建议等）都会有一段文字描述，这些文字描述为了支持多国语言，使用了一种ID的表示方法。总之，对于一个特定的编译错误提示而言，其diagnostic ID是固定的。

在我们的规范中，有些规范检测的代码在Clang中会直接编译出错，例如函数调用传递的参数个数不等于函数定义时的形参个数。当Clang编译出错时，其语法树实际上是不完善的。解决此问题的最简单办法，就是通过diagnostic实现。也就是说，我是通过将我们的特定规范映射到特定的diagnostic，当发生这个特定的编译错误时，就可以认定该规范实际上被检测到。对于简单的情况而言，这样的手段还算奏效。

// `TextDiagnosticPrinter`可以将错误信息打印在控制台上，为了调试方便我从它派生而来
class MyDiagnosticConsumer : public TextDiagnosticPrinter {
public:
    // 当一个错误发生时，会调用此函数，我会在这个函数里通过Info.getID()取得Diagnostic ID，然后对应地取出规范ID
    virtual void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
        const Diagnostic &Info) {
        TextDiagnosticPrinter::HandleDiagnostic(DiagLevel, Info);
        // 例如检查三字母词(trigraph)的使用
        if (Info.getID() == 816)
            /* 报告使用了三字母词 */
    }
};

// 初始化时需传入自己定义的diagnostic
inst.createDiagnostics(0, NULL, new MyDiagnosticConsumer(&inst.getDiagnosticOpts()));

该例子代码演示了对三字母词(wiki trigraph)使用限制的规范检测。

全文完。

Kevin Lynx 2013-02-12 21:53 发表评论

C++陷阱：构造函数中的多态

Kevin Lynx — Mon, 17 Sep 2012 08:30:00 GMT

C++中主要是通过给函数加上virtual关键字来实现多态。多态可用于改变一个接口的实现，也算是一种嵌入应用层代码到底层的实现手段。就算你用不到C++那些复杂的技术，多态肯定会被用到。

但加上virtual不一定能保证多态成功：

#include 

class Base {
public:
    Base() {
        Init();
    }

    virtual ~Base() {
        Release();
    }

    virtual void Init() {
        printf("Base::Init\n");
    }

    virtual void Release() {
        printf("Base::Release\n");
    }
};

class Derived : public Base {
public:
    virtual void Init() {
        printf("Derived::Init\n");
    }

    virtual void Release() {
        printf("Derived:Release\n");
    }
};

int main()
{
    Base *obj = new Derived();
    delete obj;
    return 0;
}

当在构造函数，包括析构函数中调用virtual函数时，预想中的多态是无法完成的，以上代码输出结果为：

Base::Init
Base::Release

从语言设计角度来看，我个人是不接受这种行为的。我觉得对一门语言而言，几乎所有特性都应该是一致的，不应该或尽量少地出现这种“例外“。如果我构造一个对象，让它以不同的方式被构造，这和改变它的某个行为有什么区别？（从这句话来看，似乎还真有区别）

当然，从语言实现来看，这样的运行结果又似乎是必然的。因为，基类的构造是早于派生类的（作为其一部分），只有当构造完派生类后，其用于支持多态的虚表才会被正确构造。也就是说，在基类中调用虚函数时，既然虚表都为正确构造，自然调用的不会是派生类的虚函数了。析构函数按照析构的顺序来看，也会面临同样的情况。

Kevin Lynx 2012-09-17 16:30 发表评论

C++陷阱：virtual析构函数

Kevin Lynx — Thu, 13 Sep 2012 09:31:00 GMT

有一天有个同事在通过vld调试一个内存泄漏问题，折腾了很久然后找到我。我瞥了一眼他的代码，发现问题和我曾经遇到的一模一样：

class Base {
public:
    ~Base();
};

class Derived : public Base {
privated:
    std::vector<int> m_data;    
};

Base *obj = new Derived();
delete obj;

当然，实际代码比这个复杂得多(这也是导致从发现问题到找到问题耗费大量时间的原因)。vld在报内存泄漏时，当然报的位置是new的地方。这个同事检查了这个对象的整个生命周期，确定他正确地释放了这个对象。

问题的关键就在于：Base类的析构函数不是virtual的。因为不是virtual，所以在对一个Base类型的指针进行delete时，就不会调用到派生类Derived的析构函数。而派生类里的析构函数会用于析构其内部的子对象，也就是这里的m_data。这样，就造成了内存泄漏。

这其实是一个很低级的失误。但毫不客气地说C++中有很多这种少个关键字或者代码位置不对就会造成另一个结果的例子。事实上，针对这些悲剧也有很多书提出一些准则来让大家去无脑遵守。例如针对这个例子，我就记得曾有书说，只要你觉得你的类会被继承，那么最好给析构函数加上virtual。

Kevin Lynx 2012-09-13 17:31 发表评论

C/c++中几种操作位的方法

Kevin Lynx — Tue, 04 Sep 2012 12:29:00 GMT

参考How do you set, clear and toggle a single bit in C?

c/c++中对二进制位的操作包括设置某位为1、清除某位（置为0）、开关某位(toggling a bit)、检查某位是否为1等。这些操作较为常见并且可以作为其他位运算的基础接口，以下罗列几种方法：

传统方法

设置某位为1

number |= 1 << x; // 设置第x位为1

清除某位

number &= ~(1 << x); // 置第x位为0

开关某位

number ^= 1 << x;

检查某位

if (number & (1 << x))

相应地我们可以将其封装起来，简便的方法是使用宏来封装：

#define BIT_SET(a,b) ((a) |= (1<<(b)))
#define BIT_CLEAR(a,b) ((a) &= ~(1<<(b)))
#define BIT_FLIP(a,b) ((a) ^= (1<<(b)))
#define BIT_CHECK(a,b) ((a) & (1<<(b)))

使用位结构操作

这个使用起来简单很多：

struct bits {
    unsigned int a:1;
    unsigned int b:1;
    unsigned int c:1;
};

struct bits mybits;

// set/clear a bit
mybits.b = 1;
mybits.c = 0;

// toggle a bit
mybits.a = !mybits.a;
mybits.b = ~mybits.b;
mybits.c ^= 1;

// check a bit
if (mybits.c)

使用STL的std::bitset

这个方法其实类似于使用位结构，只不过STL包装了这个结构定义，当然还提供了很多便捷的接口：

std::bitset<5> bits;
bits[0] = true;
bits[1] = false;
bits.set(2);
bits.flip(3);
bits.reset(2);

Kevin Lynx 2012-09-04 20:29 发表评论

C/c++中的-->运算符

Kevin Lynx — Mon, 03 Sep 2012 07:30:00 GMT

参考What is the name of this operator: “–>”?

c/c++中以下代码是合法的：

#include 
int main()
{
     int x = 10;
     while( x --> 0 ) // x goes to 0
     {
        printf("%d ", x);
     }
}

-->是一个合法的操作符，我打赌自认c/c++熟手的你们都不知道这个操作符。有人称它为goes to操作符，x-->0表示x向0趋近。

其实我在忽悠你们。 并且我相信有很多人对此把戏相当熟悉。没错，-->只是两个操作符恰好遇在了一起，他们是自减运算符--和大于比较运算符>：

while (x-- > 0)
    ...

类似的把戏还有：

while (x -- \
             \
              \
               \
                > 0)
    printf("%d ", x);

Kevin Lynx 2012-09-03 15:30 发表评论

为什么处理排序的数组要比非排序的快？

Kevin Lynx — Thu, 30 Aug 2012 09:43:00 GMT

参考Why is processing a sorted array faster than an unsorted array?

问题

看以下代码：

#include 
#include 
#include 

int main()
{
    // generate data
    const unsigned arraySize = 32768;
    int data[arraySize];

    for (unsigned c = 0; c < arraySize; ++c)
        data[c] = std::rand() % 256;


    // !!! with this, the next loop runs faster
    std::sort(data, data + arraySize);


    // test
    clock_t start = clock();
    long long sum = 0;

    for (unsigned i = 0; i < 100000; ++i)
    {
        // primary loop
        for (unsigned c = 0; c < arraySize; ++c)
        {
            if (data[c] >= 128)
                sum += data[c];
        }
    }

    double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;

    std::cout << elapsedTime << std::endl;
    std::cout << "sum = " << sum << std::endl;
}

问题就在于，去掉std::sort那一行，以上代码将运行更长的时间。在我的机器上未去掉std::sort耗时8.99s，去掉后耗时24.78s。编译器使用的是gcc4.4.3。事实上，以上代码跟编译器没有关系，甚至跟语言没有关系。那这是为什么呢？

这跟处理这个数组的逻辑有非常大的关系。如以上代码所示，这个循环里有个条件判断。条件判断被编译成二进制代码后，就是一个跳转指令，类似：

具体为什么会不同，这涉及到计算机CPU执行指令时的行为。

CPU的流水线指令执行

想象现在有一堆指令等待CPU去执行，那么CPU是如何执行的呢？具体的细节可以找一本计算机组成原理的书来看。CPU执行一堆指令时，并不是单纯地一条一条取出来执行，而是按照一种流水线的方式，在CPU真正执行一条指令前，这条指令就像工厂里流水线生产的产品一样，已经被经过一些处理。简单来说，一条指令可能经过这些过程：取指(Fetch)、解码(Decode)、执行(Execute)、放回(Write-back)。

假设现在有指令序列ABCDEFG。当CPU正在执行(execute)指令A时，CPU的其他处理单元（CPU是由若干部件构成的）其实已经预先处理到了指令A后面的指令，例如B可能已经被解码，C已经被取指。这就是流水线执行，这可以保证CPU高效地执行指令。

Branch Prediction

如上所说，CPU在执行一堆顺序执行的指令时，因为对于执行指令的部件来说，其基本不需要等待，因为诸如取指、解码这些过程早就被做了。但是，当CPU面临非顺序执行的指令序列时，例如之前提到的跳转指令，情况会怎样呢？

取指、解码这些CPU单元并不知道程序流程会跳转，只有当CPU执行到跳转指令本身时，才知道该不该跳转。所以，取指解码这些单元就会继续取跳转指令之后的指令。当CPU执行到跳转指令时，如果真的发生了跳转，那么之前的预处理（取指、解码）就白做了。这个时候，CPU得从跳转目标处临时取指、解码，然后才开始执行，这意味着：CPU停了若干个时钟周期！

这其实是个问题，如果CPU的设计放任这个问题，那么其速度就很难提升起来。为此，人们发明了一种技术，称为branch prediction，也就是分支预测。分支预测的作用，就是预测某个跳转指令是否会跳转。而CPU就根据自己的预测到目标地址取指令。这样，即可从一定程度提高运行速度。当然，分支预测在实现上有很多方法。

简单的预测可以直接使用之前的实际执行结果。例如某个跳转指令某一次产生了跳转，那么下一次执行该指令时，CPU就直接从跳转目标地址处取指，而不是该跳转指令的下一条指令。

答案

了解了以上信息后，文章开头提出的问题就可以解释了。这个代码中有一个循环，这个循环里有一个条件判断。每一次CPU执行这个条件判断时，CPU都可能跳转到循环开始处的指令，即不执行if后的指令。使用分支预测技术，当处理已经排序的数组时，在若干次data[c]>=128都不成立时（或第一次不成立时，取决于分支预测的实现），CPU预测这个分支是始终会跳转到循环开始的指令时，这个时候CPU将保持有效的执行，不需要重新等待到新的地址取指；同样，当data[c]>=128条件成立若干次后，CPU也可以预测这个分支是不必跳转的，那么这个时候CPU也可以保持高效执行。

相反，如果是无序的数组，CPU的分支预测在很大程度上都无法预测成功，基本就是50%的预测成功概率，这将消耗大量的时间，因为CPU很多时间都会等待取指单元重新取指。

本文完。最后感叹下stackoverflow上这个帖子里那个老外回答问题的专业性，我要是楼主早就感动得涕泪横飞了。感谢每一个传播知识的人。

参考资料

Kevin Lynx 2012-08-30 17:43 发表评论

使用memcmp比较两个变量结果一定吗？

Kevin Lynx — Fri, 17 Aug 2012 06:07:00 GMT

参考Is using memcmp on array of int strictly conforming?

以下代码一定会输出ok吗？

#include 
#include 

struct S { int array[2]; };

int main () {
    struct S a = { { 1, 2 } };
    struct S b;
    b = a;
    if (memcmp(b.array, a.array, sizeof(b.array)) == 0) {
        puts("ok");
    }
    return 0;
}

我在vs2005以及gcc4.4.3上做了测试，都输出了ok。但这并不意味这个代码会永远输出ok。问题主要集中于这里使用了赋值语句来复制值，但却使用了memcmp这个基于内存数据比较的函数来比较值。

c语言中的赋值运算符（=）被定义为基于值的复制，而不是基于内存内容的复制。

C99 section 6.5.16.1 p2: In simple assignment (=), the value of the right operand is converted to the type of the assignment expression and replaces the value stored in the object designated by the left operand.

这个其实很好理解，尤其在不同类型的数字类型间复制时，例如：

float a = 1.1;
int b = a;

因为浮点数和整形数的内存布局不一样，所以肯定是基于值的一种复制。另外，按照语言标准的思路来看，内存布局这种东西一般都属于实现相关的，所以语言标准是不会依赖实现去定义语言的。

上面的定理同样用于复杂数据类型，例如结构体。我们都知道结构体每个成员之间可能会有字节补齐，而使用赋值运算符来复制时，会不会复制这些补齐字节的内容，是语言标准未规定的。这意味着使用memcmp比较两个通过赋值运算符复制的两个结构体时，其结果是未定的。

但是上面的代码例子中，比较的其实是两个int数组。这也无法确认结果吗？这个问题最终集中于，难道int也会有不确定的补齐字节数据？

C99 6.2.6.2 integer types For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. […] The values of any padding bits are unspecified.

这话其实我也不太懂。一个有符号整数int，其内也有补齐二进制位(bits)？

但无论如何，这个例子都不算严谨的代码。人们的建议是使用memcpy来复制这种数据，因为memcpy和memcmp都是基于内存内容来工作的。

Kevin Lynx 2012-08-17 14:07 发表评论

像写函数式语言代码一样写C++

Kevin Lynx — Tue, 31 Jul 2012 01:43:00 GMT

忘记最早接触函数式编程语言是什么时候了，也忘记接触的第一门函数式语言是哪一门。断断续续接触过好几种函数式语言（当然都算不纯的，ruby/lisp不算纯吧），这些语言的思想在潜移默化中多多少少对我有所影响。

我是个C++程序员，我不知道我平时写的都是些什么代码。最让人印象深刻就是我会经常写遍历STL容器的代码，是经常，这样的遍历你可能也不陌生：

for (ListType::iterator it = con.begin(); it != con.end(); ++it) {
    something
}

或者针对std::map/set等的查找：

Table::iterator it = table.find(key);
if (it == table.end())
    do-something
do-something

多亏STL接口的一致性，这让我们写出了很多“一致性“代码。慢慢地我觉得恶心，不禁想起函数式编程语言中，对于这种需求一般都会提供类似的接口：

con.map(function (it) if (it->some-filed == some-value) return something end)
# 或者
con.each do |it| if it.some-filed == some-value then return something end end
# 或者
(con.map (lambda (it) (if ((= it.some-filed some-value)) (return something))))

（好吧，lisp我又忘了）总之，这种针对容器的遍历操作，都会成为一种内置接口，并且通过lambda来让用户直接编写处理代码，少去写循环的冗余。然后，我写了类似下面的一组宏（随手敲的不保证能运行）：

#define IT_N __it

#define TRAVERSE_MAP(type, map, exps) \
    for (type::iterator IT_N = map.begin(); IT_N != map.end(); ++IT_N) { \
        exps; \
    }
#define I_KEY (IT_N->first)
#define I_VALUE (IT_N->second)

#define TRAVERSE_LIST(type, list, exps) \
    for (type::iterator IT_N = list.begin(); IT_N != list.end(); ++IT_N) { \
        exps; \
    }
#define L_VALUE (*IT_N)

#define FIND_MAP_ITEM(type, map, key, fexps, texps) \
    do { \
        type::iterator IT_N = map.find(key); \
        if (IT_N == map.end()) { \
            fexps; \
        } else { \
            texps; \
        } \
    } while(0)

#define VAL_N __val
#define FIND_LIST_ITEM_IF(type, list, cmp, fexps, texps) \
    do { \
        struct Comp { \
            bool operator() (const type::value_type &VAL_N) const { \
                return cmp; \
            } \
        }; \
        type::iterator IT_N = std::find_if(list.begin(), list.end(), Comp()); \
        if (IT_N != list.end()) { \
            texps; \
        } else { \
            fexps; \
        } \
    } while(0)

#define NULL_EXP ;

当然，以上接口都还包含一些const版本，用于const容器的使用。使用的时候（截取的项目中的使用例子）：

TRAVERSE_MAP(TimerTable, m_timers, 
        I_VALUE.obj->OnTimerCancel(I_KEY, I_VALUE.arg);
        TIMER_CANCEL(I_VALUE.id)); 

TRAVERSE_LIST(AreaList, areas,
        ids.push_back(L_VALUE->ID()));

FIND_MAP_ITEM(PropertyTable, m_properties, name,
        LogWarn("set a non-existed property %s", name.c_str()); return NIL_VALUE,
        if (val.Type() != I_VALUE.type()) {
            return NIL_VALUE; 
        } else {
            GValue old = I_VALUE;
            I_VALUE = val; 
            return old;
        });

多亏了C/C++宏对一切内容的可容纳性，可以让我往宏参数里塞进像if这种复合语句，甚至多条语句（例如最后一个例子）。这些宏我使用了一段时间，开始觉得挺爽，很多函数的实现里，我再也不用写那些重复的代码了。但是后来我发觉这些代码越来越恶心了。最大的弊端在于不可调试，我只能将断点下到更深的代码层；然后就是看起来特不直观，连作者自己都看得觉得不直观了，可想而知那些连函数式编程语言都不知道是什么的C++程序员看到这些代码会是什么心情（可以想象哥已经被诅咒了多少次）。

函数式语言让人写出更短的代码，这一点也对我有影响，例如我最近又写下了一些邪恶代码：

// split a string into several sub strings by a split character i.e:
// "a;b;c;" => "a", "b", "c"
// "a;b;c" => "a", "b", "c"
std::vector<std::string> SplitString(const std::string &str, char split) {
    std::vector<std::string> ret;
    size_t last = 0;
    for (size_t pos = str.find(split); pos != std::string::npos; last = pos + 1, pos = str.find(split, last)) {
        ret.push_back(str.substr(last, pos - last));
    }
    return last < str.length() ? ret.push_back(str.substr(last)) : 0, ret;
}

恶心的就是最后那条return语句，因为我需要处理”a;b;c”这种c后面没加分隔符的情况，但我并不愿意为了这个需求再写一个会占超过一行的if语句。因为，我太喜欢ruby里的if了：

do-something if exp

也就是ruby里允许这种只有一行if的代码将if放在其后并作为一条语句。我的不愿意其实是有理由的，在c/c++中有太多只有一行条件体的if语句，对这些语句参合进编程风格/可读性进来后，就不得不让你写出不安的代码，例如：

if (something) return something; // 某些编程风格里不允许这样做，因为它不方便调试

if (something) 
    return something; // 某些风格里又有大括号的统一要求

if (something) {
    return something; // 就算符合风格了，但这一条语句就得多个大括号
}

if (something) 
{
    return something; // 某些风格里这大括号就更奢侈了
}

这个return除了乍看上去有点纠结外，其实也不算什么大问题，但是那个问号表达式返回的0实在没有任何意义，而正是没有意义才会让它误导人。本来我是可以写成：

return last < str.length() && ret.push_back(str.substr(last)), ret;

这样利用条件表达式的短路运算，代码也清晰多了。但是，std::vector::push_back是一个没有返回值的函数，所以。

全文完。

Kevin Lynx 2012-07-31 09:43 发表评论

tolua的tolua_toxxx系列API设计

Kevin Lynx — Thu, 10 May 2012 07:38:00 GMT

原文链接：http://codemacro.com/2012/05/10/tolua-api/

我们使用tolua++手工绑定c/c++接口到lua中，在绑定的接口实现里，就需要取出传入的参数。tolua++中提供了一系列tolua_toxxx函数，例如：

lua_Number tolua_tonumber(lua_State *L, int narg, lua_Number def)
const char *tolua_tostring(lua_State *L, int narg, const char *def)

这些函数都有一个def参数。乍一看，这些函数使用起来很简单。传入lua_State，传入参数在栈中的位置，然后再传一个失败后返回的默认值。

我重点要说的是这里这个失败，按正常程序员的理解，针对lua而言，什么情况下算失败呢？lua语言里函数参数支持不传，此时实参为nil，将nil转换为一个c类型必然失败；参数类型不正确算不算失败？你传一个user data，c里按数字来取，这也算失败。

这么简单的API还需要多纠结什么呢？然后我们浩浩荡荡地写了上百个接口，什么tolua_tostring/tolua_tonumber的使用少说也有500了吧？

然后有一天，服务器宕机了，空指针:

/* 失败返回""，还能省空指针的判断 */
const char *name = tolua_tostring(L, 1, "");
if (name[0] == '\0') { /* 空串总得判断吧 */
 ...
}

跟踪后发现，脚本里传入的是nil，这里的name取出来是NULL，而不是”“（的地址）。然后吐槽了一下这个API，辛苦地修改了所有类似代码，增加对空指针的判断。我没有多想。

故事继续，有一天服务器虽然没宕机，但功能不正常了:

float angle = (float) tolua_tonumber(L, 1, 2 * PI);
...

这个意思是，这个函数的参数1默认是2*PI，什么是默认？lua里某函数参数不传，或传nil就是使用默认。因为不传的话，这个实参本身就是nil。但，tolua_tonumber的行为不是这样的，它的实现真是偷懒:

TOLUA_API lua_Number tolua_tonumber (lua_State* L, int narg, lua_Number def)
{
 return lua_gettop(L)<abs(narg) ? def : lua_tonumber(L,narg);
}
TOLUA_API const char* tolua_tostring (lua_State* L, int narg, const char* def)
{
 return lua_gettop(L)<abs(narg) ? def : lua_tostring(L,narg);
}

意思是，只有当你不传的时候，它才返回默认值，否则就交给lua的API来管，而lua这些API是不支持应用层的默认参数的，对于lua_tonumber错误时就返回0，lua_tostring错误时就返回NULL。

这种其行为和其带来的common sense不一致的API设计，实在让人蛋疼。什么是common sense呢？就像一个UI库里的按钮，我们都知道有click事件，hover事件，UI库的文档甚至都不需要解释什么是click什么是hover，因为大家看到这个东西，就有了共识，无需废话，这就是common sense。就像tolua的这些API，非常普通，大家一看都期待在意外情况下你能返回def值。但它竟然不是。实在不行，你可以模仿lua的check系列函数的实现嘛:

LUALIB_API lua_Number luaL_checknumber (lua_State *L, int narg) {
 lua_Number d = lua_tonumber(L, narg);
 if (d == 0 && !lua_isnumber(L, narg)) /* avoid extra test when d is not 0 */
 tag_error(L, narg, LUA_TNUMBER);
 return d;
}

即，根本不用去检查栈问题，直接在lua_tonumber之后再做包装检查。何况，lua需要你去检查栈吗？当你访问了栈外的元素时，lua会自动返回一个全局常量luaO_nilobject:

static TValue *index2adr(lua_State *L, int idx) {
 ...
 if (o >= L->top) return cast(TValue*, luaO_nilobject);
}

另，程序悲剧也来源于臆想。

Kevin Lynx 2012-05-10 15:38 发表评论

多重继承和void*的糗事

Kevin Lynx — Sat, 30 Apr 2011 12:14:00 GMT

多重继承和void*的糗事

Author:	Kevin Lynx
Date:	4.30.2011

C++为了兼容C，导致了不少语言阴暗面。Bjarne Stroustrup在一书里也常为此表现出无奈。另一方面，强制转换也是C++的一大诟病。但是，因为我们的应用环境总是那么“不纯”，所以也就常常导致各种问题。

本文即描述了一个关于强制转换带来的问题。这个问题几年前我曾遇到过(<多线程下vc2003,vc2005对虚函数表处理的BUG？>)，当时没来得及深究。深究C++的某些语法，实在是件辛苦事。所以，这里也不提过于诡异的用法。

问题

考虑下面非常普通的多重继承代码:

class Left {
public:
    virtual void ldisplay () {
        printf ("Left::ldisplay\n");
    }
};

class Right {
public:
    virtual void rdisplay () {
        printf ("Right::rdisplay\n");
    }
};

class Bottom : public Left, public Right {
public:
    virtual void ldisplay () {
        printf ("Bottom::ldisplay\n");
    }
};

这样子的代码在我们的项目中很容易就会出现，例如:

class BaseObject;
class EventListener;
class Player : public BaseObject, public EventListener

别紧张，我当然不会告诉你这样的代码是有安全隐患的。但它们确实在某些时候会出现隐患。在我们的C++项目中，也极有可能会与一些纯C模块打交道。在C语言里，极有肯能出现以下的代码:

typedef void (*allocator) (void *u);
void set_allocator (allocator alloc, void *u);

之所以使用回调函数，是出于对模块的通用性的考虑。而在调用回调函数时，也通常会预留一个user data的指针，用于让应用层自由地传递数据。

以上关于多重继承和void*的使用中，都属于很常规的用法。但是当它们遇到一起时，事情就悲剧了。考虑下面的代码:

Bottom *bobj = new Bottom(); // we HAVE a bottom object
Right *robj = bobj; // robj point to bobj?
robj->rdisplay(); // display what ?
void *vobj = bobj; // we have a VOID* pointer
robj = (Right*) vobj; // convert it back
robj->rdisplay(); // display what?

这里的输出结果是什么呢？:

Right::rdisplay
Bottom::ldisplay // !!!!

由void*转回来的robj调用rdisplay时，却调用了莫名其妙的Bottom::ldisplay！

多重继承类的内存布局

类对象的内存布局，并不属于C++标准。这里仅以vs2005为例。上面例子中，Bottom类的内存布局大概如下:

+-------------+
| Left_vptr   |
+-------------+
| Left data   |
+-------------+
| Right_vptr  |
+-------------+
| Right data  |
+-------------+
| Bottom data |
+-------------+

与单继承不同的是，多重继承的类里，可能会包含多个vptr。当一个Bottom对象被构造好时，其内部的两个vptr也被正确初始化，其指向的vtable分别为:

Left_vptr --->  +---------------------+
                | 0: Bottom::ldisplay |
                +---------------------+

Right_vptr ---> +---------------------+
                | 0: Right::rdisplay  |
                +---------------------+

转换的内幕

类体系间的转换

隐式转换相比强制转换而言，一定算是优美的代码。考虑如下代码的输出:

Bottom *bobj = new Bottom();
printf ("%p\n", bobj);
Right *robj = bobj;
printf ("%p\n", robj);

其输出结果可能为:

003B5DA0
003B5DA4

结论就是，Right *robj = bobj;时，编译器返回了bobj的一个偏移地址。 从语言角度看，就是这个转换，返回了bobj中Right*的那一部分的起始地址。但编译器并不总是在bobj上加一个偏移，例如:

bobj = NULL;
Right *robj = bobj;

编译器不会傻到给你一个0x00000004的地址，这简直比NULL更无理。

void*转换

编译器当然有理由做上面的偏移转换。那是因为在编译阶段，编译器就知道bobj和Right之间的关系。这个偏移量甚至不需要在运行期间动态计算，或是从某个地方取。如果你看过上面代码对应的汇编指令，直接就是:

add eax, 4 ; 直接加 sizeof(Left)，记住，Right在Left之后

void*就没那么幸运了。void*和Bottom没有任何关系，所以:

void *vobj = bobj; // vobj的地址和bobj完全相同

然后当你将vobj转换到一个Right*使用时:

robj = (Right*) vobj;  // 没有偏移转换，robj == vobj == bobj
robj->rdisplay();

robj指向的是Bottom的起始地址，天啊，在我们学习C++时，我们可以说Bottom就是一个Left，也是一个Right，所谓的is kind of。但这里的悲剧在于，按照上面的逻辑，我们在使用Right时，其实应该使用Bottom里Right那一部分。 但现在这个转换，却让robj指向了Bottom里Left那一部分。

当调用 robj->rdisplay 时，编译器当然按照Right的内存布局，生成一个虚函数的调用指令，大概就是:

mov vptr, robj->[0] ;; vptr在robj起始地址处
mov eax, vptr[0] ;; rdisplay在vtable中位于第一个
mov ecx, robj
call eax

总而言之， robj->rdisplay 就是使用偏移0处的值作为vptr，然后使用vptr指向的vtable中第一个函数作为调用。

但，robj正指向bobj的起始地址，这个地址是放置Left_vptr的地方。这个过程，使用了Left_ptr，而Left_ptr指向的vtable中，第一个函数是什么呢？:

Left_vptr --->  +---------------------+
                | 0: Bottom::ldisplay |
                +---------------------+

正是Bottom::ldisplay！到这里，整个问题的原因就被梳理出来了。

;;END;;

Kevin Lynx 2011-04-30 20:14 发表评论

逆向思路：破解飞秋群聊协议

Kevin Lynx — Sun, 23 Jan 2011 13:01:00 GMT

题外

飞秋是一款局域网内的IM软件，界面类似QQ，实现上与飞鸽（IP message）有点渊源，免费，不开源。

公司大概两年前开始使用这款软件作为员工之间办公吹牛的工具。最近游戏玩得少，就想彻底换到linux下，

组内也有其他两人是llinux-er，不过悲剧的是换到linux下就无法收取飞秋群里的聊天信息了，不免寂寞。

所以，就想写个协议兼容的程序（或者说改个东西）来收取群信息。

准备

我本身并不擅长逆向工程，破解什么的纯碎业余。在GOOGLE/BAIDU之后发现并没有前人留下的成果。

使用抓包程序，以及综合网络上的信息，还是可以得出不少有用的信息：

# 飞秋兼容了飞鸽的协议，其协议格式基本上基于文本形式，各个内容之间使用冒号作为分隔，例如：

1:100:user:pcname:32:message_body

# 飞秋在私聊情况下的消息内容是没有加密的，但群聊信息加密了，解密这个内容也是我的目标所在

# 在抓包软件下根据消息的目标IP地址可以推断飞秋发送群信息是基于UDP组播的，即就算你不是这个群

的成员，也会收到群消息

有用的文章：《局域网内实现飞鸽欺骗》、《飞鸽传书数据加密分析》(个人感觉没有任何实质内容，而

且飞鸽传书并不是飞秋，属于误导性文章，但是依然有用）。最重要的，稍微浏览IP message的代码，

以及linux下的iptux（另一个兼容飞鸽的局域网IM）代码，都是对接下来的破解有益的。

破解

我希望我提供更多的，是一种crack的思路，虽然我不是一个cracker。破解和写程序不太一样，它需要

更多的耐心、运气、程序之外的思考。如前所做的准备，尤其重要。

工具及环境：飞秋2.4版本、OllyDbg，为了方便接收群信息，最好有两台电脑。

STEP 1 找入手点

在开始面对一大推汇编代码时，我们需要一个最接近目标的点。获取这个点根据目标的不同而不同。例如，

这里主要是针对网络数据的解密。所以，最直接的就是去找这些网络数据。当然，根据具体程序的表现，也

可以从其他点入手，例如飞秋收到群消息后会在任务栏闪烁图标，也可以从这个功能逆向过去。

因为飞秋使用UDP协议，所以我们可以在recvfrom函数下断点（bp recvfrom）。因为接收UDP包的接口

可能还有WSARecvFrom，甚至winsock1.0中的recvfrom，所以最好都下断点。另一台机器发送群消息，

程序在winsock1.0里的recvfrom断下来：

71A43001 > 8BFF            mov     edi, edi
71A43003    55              push    ebp
71A43004    8BEC            mov     ebp, esp
71A43006    51              push    ecx

这个不是我们需要的，我们需要根据这个点获得用户层代码，这将是整个破解过程的起点。所以，OD中

ALT+K查看调用堆栈，然后跳到调用recvfrom的函数处：

00490890 /$ 56            push    esi                              ; 接收数据的函数入口
00490891 |. 8B7424 08     mov     esi, dword ptr [esp+8]
00490895 |. 8D46 10       lea     eax, dword ptr [esi+10]
00490898 |. 50            push    eax                              ; /pFromLen
00490899 |. 56            push    esi                              ; |pFrom
0049089A |. C700 10000000 mov     dword ptr [eax], 10              ; |
004908A0 |. 8B09          mov     ecx, dword ptr [ecx]             ; |
004908A2 |. 6A 00         push    0                                ; |Flags = 0
004908A4 |. 8D46 18       lea     eax, dword ptr [esi+18]          ; |
004908A7 |. 68 FF3F0000   push    3FFF                             ; |BufSize = 3FFF (16383.)
004908AC |. 50            push    eax                              ; |Buffer
004908AD |. 51            push    ecx                              ; |Socket
004908AE |. E8 C7F30C00   call                   ; \recvfrom

邪恶的OD已经将调用recvfrom时传入参数的指令标记出来了。中文注释是我分析时加的。recvfrom里传入

的接收缓存，是我们应该关注的。如果能跟进这个缓存，假设程序的流程比较简单：接收了数据，然后在某个

地方直接解密，不管它的加密方式是什么，只要能找到这个缓存数据从加密变为解密的地方，对于整个破解而言，

都算是迈进了一大步。

于是，在00490890（上面找到的函数入口）下断点，准备跟进接收缓存。注意：在OD里调试跟在vc里不一样，

跳到调用堆栈里的某个函数，寄存器依然是当前的值。所以需要重新跟。

STEP 2 内存断点

F9让程序继续运行，再次在另一台机器上发送群消息。这回程序在00490890处断下，然后跟接收缓存：

接收缓存Buffer的值为0011F4CC，如前所述，我们要跟进这个地址指向的内存的变化情况。F8单步运行到

recvfrom后，也就是接收了网络数据后，查看内存内容

(d 0011F4CC)：

0011F4CC 31 5F 6C 62 74 34 5F 30 23 31 32 38 23 38 38 41 1_lbt4_0#128#88A
0011F4DC 45 31 44 44 34 36 36 46 44 23 30 23 30 23 37 32 E1DD466FD#0#0#72
0011F4EC 3A 31 32 39 35 37 32 31 32 31 33 3A 41 64 6D 69 :1295721213:Admi
0011F4FC 6E 69 73 74 72 61 74 6F 72 3A 50 43 2D 32 30 31 nistrator:PC-201
0011F50C 30 31 31 30 34 32 30 30 35 3A 34 31 39 34 33 33 011042005:419433
0011F51C 39 3A 5E 3B 83 A1 14 6D A4 D2 E3 D8 E8 AB B1 3A 9:^;儭mひ阖璜?
0011F52C 5B BC C2 FE E9 DA CB DD 00 BC 59 FC 9D A7 D7 91 [悸谒?糦鼭ё

内容开头正是飞秋的协议头，未加密，不过没多大用。根据之前获取的飞秋协议，可知，在0011F51E

处就是聊天内容的密文。

很自然地，为了监视这段内存的变化情况，在该位置下内存访问断点（右击数据区即可看到下断点的选项）。

F9继续走，然后马上断下来：

0049010F |. F3:A5         rep     movs dword ptr es:[edi], dword ptr [>
00490111 |. 8B4A 04       mov     ecx, dword ptr [edx+4]
00490114 |. C74424 24 000>mov     dword ptr [esp+24], 0
0049011C |. 894D 64       mov     dword ptr [ebp+64], ecx
0049011F |. 33C9          xor     ecx, ecx

程序到了一个陌生的环境（在这种满世界都是汇编代码的情况下，几乎一不小心就会迷失其中），看了下

附近的代码，没什么可疑。通过下内存访问断点的思路，似乎显得荆棘丛生。

STEP 3 靠近目标

不妨冷静下来思考，如果没有直接的路，我们可能需要悲惨地大海捞针。在写一个网络程序时，网络底层

收到数据包，无非要么直接进行逻辑处理，要么缓存到一个逻辑处理队列里稍后处理。后者虽然对于程序员

而言是个好方法，但是因为跨了线程，又涉及到队列缓存，对于逆向而言，绝对是悲剧。

但是如果使用了前者呢？对于一个网络客户端程序而言，也许直接进行逻辑处理才是最KISS的方法。（这种猜测

的破解方式，绝对需要运气。）所以，如果是直接进行处理，那么在接收到网络数据附近，必然就有解密函数。

所以，不妨顺着收包函数附近随意浏览一番。（但不要走进太深的call，不然又迷失了。）

0048FE10 /$ B8 18400000   mov     eax, 4018
0048FE15 |. E8 560A0C00   call    00550870
0048FE1A |. 8D4424 00     lea     eax, dword ptr [esp]
0048FE1E |. 56            push    esi
0048FE1F |. 8BF1          mov     esi, ecx
0048FE21 |. 50            push    eax
0048FE22 |. E8 690A0000   call    00490890                             ; 接收网络数据

0048FE10函数调用了刚才发现的收包函数。这个函数在收完数据后，不久就调用了另一个函数：

0048FE3F |. 51            push    ecx
0048FE40 |. 52            push    edx
0048FE41 |. 8BCE          mov     ecx, esi
0048FE43 |. E8 88020000   call    004900D0                             ; 似乎很可疑？

进到004900D0函数，发现这个函数真TMD巨大。随意浏览之，发现OD有这种提示：

00490178 |. 68 34FD5E00   push    005EFD34                             ; ASCII "_lbt"
0049017D |. 8D4C24 14     lea     ecx, dword ptr [esp+14]
00490181 |. 89BC24 544000>mov     dword ptr [esp+4054], edi

_lbt，恩，消息头里有这个字符串标识。估计是在做些消息头的逻辑操作。这个函数太长，里面还有若干call，

可谓头大。所以说，代码写得丑，可读性差，对于防破解还是颇有益处的。跳回到0048FE43，发现当前

函数基本完了。

于是往上看，来到调用这个函数的地方：

0050F647 |. E8 C407F8FF call 0048FE10
0050F64C |. BF 01000000 mov edi, 1

回顾下，我们有函数A接收网络数据，有函数B调用A，现在回到了C，来到了调用B的地方0050F647。C函数

也很巨大，直接往下浏览，会发现一些switch语句：

0050F71A |. 81E6 FF000000 and     esi, 0FF
0050F720 |. 8D46 FF       lea     eax, dword ptr [esi-1]               ; Switch (cases 1..D3)
0050F723 |. 3D D2000000   cmp     eax, 0D2
0050F728 |. 0F87 8C000000 ja      0050F7BA
0050F72E |. 33C9          xor     ecx, ecx
0050F730 |. 8A88 60315100 mov     cl, byte ptr [eax+513160]
0050F736 |. FF248D 403051>jmp     dword ptr [ecx*4+513040]
0050F73D |> 8D9424 F40000>lea     edx, dword ptr [esp+F4]              ; Case 1 of switch 0050F720

往后浏览下这个switch…case，发现非常之大，这个函数也因此非常巨大。不妨猜测这个是根据不同消息做不同

逻辑处理的地方。这个想法正是给予我们灵感的关键。

群聊消息必然也有个类型，通过之前OD获取到的网络数据（或者截取网络封包所得），群聊消息的类型为：4194339

（16进制400023H），去掉高位，也就是23H。仔细地对比每一个case，果然发现了一段处理代码：

00512787 |> \39AC24 640100>cmp     dword ptr [esp+164], ebp             ; Case 23 of switch 0050F720
0051278E |. 75 07         jnz     short 00512797                       ; 群聊天处理
00512790 |. 8BC7          mov     eax, edi
00512792 |. E9 8C080000   jmp     00513023

这个代码之下的处理也有不少代码。在不涉及到更多细节之前，我们可以大胆地将注意力放在接下来的call上。从这个case

往下，第一个call为：

005127E6 |. 50            push    eax
005127E7 |. E8 A4A20000   call    0051CA90                             ; 非常可疑
005127EC |. B8 01000000   mov     eax, 1
005127F1 |. E9 2D080000   jmp     00513023

STEP 4 多尝试

有怀疑，就用事实来证明。果断地在005127E6处下断点。然后发群消息，程序断下来。因为这个函数压入了

eax作为参数，且对ecx做了赋值：

005127E4 |. 8BCB          mov     ecx, ebx
005127E6 |. 50            push    eax
005127E7 |. E8 A4A20000   call    0051CA90                             ; 非常可疑

在调用一个函数前对ecx做赋值，一般都是C++成员函数调用。eax作为一个参数，非常值得关注，果断查看eax

指向的内存值：

001235C8 41 64 6D 69 6E 69 73 74 72 61 74 6F 72 00 6D 00 Administrator.m.
001235D8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001235E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001235F8 00 00 50 43 2D 32 30 31 30 31 31 30 34 32 30 30 ..PC-20101104200
00123608 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5...............
00123618 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00123628 8A 7B 00 00 C0 A8 00 03 09 79 00 00 01 00 00 00 妠..括..y.....
00123638 04 00 00 00 00 00 00 00 80 00 00 00 38 38 41 45 .......€...88AE
00123648 31 44 44 34 36 36 46 44 00 00 00 00 00 00 00 00 1DD466FD........
00123658 00 00 00 00 F4 C7 23 00 FD 22 3B 4D 23 00 40 00 ....羟#.?;M#.@.
00123668 49 00 00 00 36 00 00 00 5E 3B 83 A1 14 6D A4 D2 I...6...^;儭mひ

有用户名、机器名、发送者MAC地址，这么多可疑信息。完全可以猜测，eax传入的是一个结构体地址，

当然对象地址也可以，反正是个复杂数据结构。更重要的，在这块内存往下不远处，果断地发现了从

网络接收到的加密的聊天内容：

00123670 5E 3B 83 A1 14 6D A4 D2 E3 D8 E8 AB B1 3A 5B BC ^;儭mひ阖璜?[
00123680 C2 FE E9 DA CB DD 00 BC 59 FC 9D A7 D7 91 CF 5A 漫橼溯.糦鼭ё懴Z

F8直接步过0051CA90函数。任务栏开始出现闪烁的图标（虽然没有闪），上面的内存数据变了：

00123670 74 65 73 74 7B 2F 66 6F 6E 74 3B 2D 31 34 20 30 test{/font;-14 0
00123680 20 30 20 30 20 34 30 30 20 30 20 30 20 30 20 31 0 0 400 0 0 0 1
00123690 33 34 20 33 20 32 20 31 20 32 20 CB CE CC E5 20 34 3 2 1 2 宋体

test正是我发的内容。

STEP 5 缩小范围

实际上走到这里，凭借运气和程序编写的常识，已经找到关键点。不过看来0051CA90这个函数做的事情

有点多，除了解密内容似乎还有UI上的一些处理（例如那个闪烁的任务栏图标）。所以，我们要做的是，进一步

跟进，找到关键点。

现在缩小范围要容易得多，因为我们得到了一个会变化的内存地址：00123670。只需要F8一步一步地

运行代码，一旦发现内存内容改变，则可以进一步进如，从而找到关键call。具体过程我就不给了，大概为：

00490DB0 |. 6A 00         push    0
00490DB2 |. 83E1 03       and     ecx, 3
00490DB5 |. 6A 22         push    22
00490DB7 |. F3:A4         rep     movs byte ptr es:[edi], byte ptr [es>
00490DB9 |. 8BBC24 344000>mov     edi, dword ptr [esp+4034]
00490DC0 |. 50            push    eax                                  ; 数据长度
00490DC1 |. 8D4424 20     lea     eax, dword ptr [esp+20]
00490DC5 |. 57            push    edi                                  ; 输出缓存
00490DC6 |. 50            push    eax                                  ; 输入缓存（加密内容）
00490DC7 |. 8D4C24 20     lea     ecx, dword ptr [esp+20]
00490DCB |. E8 5049F7FF   call    00405720                             ; 最终解密函数

00405720函数内的实现基本上全是数据操作指令。加解密算法无非就是捣鼓这些数据，所以当我进到

00405720函数时，基本上可以断定它就是最终的解密函数。

STEP 6 解密

事实上我们并不需要去弄懂它的具体解密算法，就算是直接的C++代码，没有算法论文的话也很难看懂，更何况

是这里的汇编。最直接的方式，就是查看这个解密函数对外界的依赖情况，例如需要的参数，this里是否有依赖

的数据。在了解了这些情况后，大可以将这段汇编复制出来直接作为C++内嵌汇编代码使用。

不过，这里我想到了更简单的方式。因为我注意到飞秋和飞鸽在实现上有着不解之缘，而且我琢磨着作者也不会

为了一个加解密不太重要的应用场合而去整些高深的算法。我想到，飞秋也许会直接使用飞鸽里的加解密代码！

在IP message的源码里，有blowfish加密算法的实现，我们来看接口：

class CBlowFish
{
private:
    DWORD    *PArray;
    DWORD    (*SBoxes)[256];
    void    Blowfish_encipher(DWORD *xl, DWORD *xr);
    void    Blowfish_decipher(DWORD *xl, DWORD *xr);

public:
            CBlowFish(const BYTE *key=NULL, int keybytes=0);
            ~CBlowFish();
    void    Initialize(const BYTE *key, int keybytes);
    DWORD    GetOutputLength(DWORD lInputLong, int mode);
    DWORD    Encrypt(const BYTE *pInput, BYTE *pOutput, DWORD lSize, int mode=BF_CBC|BF_PKCS5, _int64 IV=0);
    DWORD    Decrypt(const BYTE *pInput, BYTE *pOutput, DWORD lSize, int mode=BF_CBC|BF_PKCS5, _int64 IV=0);
};

从接口实现来说算是简洁漂亮友好和谐。我也用Decrypt这个函数的参数比对了上面没找到的那个call（00405720），

因为这里只是怀疑这个call就是这里的Decrypt，但并没有确切的证据。不过，对比下他们的参数就可以非常肯定了：

00490DB0 |. 6A 00         push    0           ;参数IV
00490DB2 |. 83E1 03       and     ecx, 3
00490DB5 |. 6A 22         push    22        ;参数mode
00490DB7 |. F3:A4         rep     movs byte ptr es:[edi], byte ptr [es>
00490DB9 |. 8BBC24 344000>mov     edi, dword ptr [esp+4034]
00490DC0 |. 50            push    eax                                  ; 参数数据长度
00490DC1 |. 8D4424 20     lea     eax, dword ptr [esp+20]
00490DC5 |. 57            push    edi                                  ; 参数输出缓存
00490DC6 |. 50            push    eax                                  ; 参数输入缓存（加密内容）
00490DC7 |. 8D4C24 20     lea     ecx, dword ptr [esp+20]
00490DCB |. E8 5049F7FF   call    00405720                             ; 最终解密函数

最重要的，是参数mode。Decrypt默认参数mode是BF_CBC|BF_PKCS5的位组合，结果，恰好为22！

所以，基本上可以断定：飞秋的加解密实现，就是使用了IP message的blowfish算法：blowfish.cpp/h/h2。

STEP 7 密钥

查看CBlowFish的使用，在解密前需要初始化，大概就是传入密钥之类。如果我们上面的猜测没有错，那么我们

从网络上取得的数据，然后取得密钥，直接使用blowfish的源码，就可以解密出消息内容。

接下来的关键就是，找到这个密钥。关于这个密钥，之前在飞秋的配置文件FeiqCfg.xml里绕了很久的圈子，因为

发现加入一个群的时候，这个文件里就会多出一项很长的16进制字符串。也一度猜测密钥就是保存在这个字符串的

某个偏移里。接下来会让人大跌眼镜。

因为CBlowFish这个类确实简单，使用它的最简单方式就是直接创建局部对象，然后传入key和keysize，即可完成

初始化。在之前展示的思路里，我也一度先去尝试最简单的方法。对于C++局部对象的创建，有个显著特征就是

mov ecx, dword ptr [esp+xxx]，也就是往ecx里写入一个栈地址。而且可以肯定的是，这个构造代码，必然发生

于call 00405720前面不远处，往上跟进：

一个压入两个参数的函数调用，对比CBlowFish的构造函数，刚好是2个参数。跟进00404A90：

又是可爱的立即数！48H、1000H，这种特别的立即数总能让人安心，对比CBlowFish构造函数实现：

CBlowFish::CBlowFish (const BYTE *key, int keybytes)
{
PArray = new DWORD [NPASS + 2];//NPASS=16
SBoxes = new DWORD [4][256];

if (key)
Initialize(key, keybytes);
}

sizeof(DWORD)*18=48H，sizeof(DWORD)*4*256=1000H！这么极具喜剧意义的汇编C++代码映射，

基本可以肯定，00404AA1处，正是构造CBlowFish对象的地方，而构造的参数，正是我们魂牵梦萦的解密密钥：

00490D46 |> \51            push    ecx                                  ; key长度
00490D47 |. 52            push    edx                                  ; 密钥key
00490D48 |. 8D4C24 0C     lea     ecx, dword ptr [esp+C]
00490D4C |. E8 3F3DF7FF   call    00404A90                             ; 构造blowfish对象

在此处下断点，发送群消息，程序断下来，看看密钥究竟是什么。如果它确实是FeiqCfg.xml里的某个值，

那么我们还要进一步跟这个值具体在哪个配置项里。看看吧，密钥edx：

edx=00123644, (ASCII "88AE1DD466FD")

TM的密钥居然是发送者的MAC地址！当我看到这个的时候我几乎快摔倒地上。如果飞秋使用一个MAC地址

作为密钥，那么这意味着：通过自己写的程序，可以取得局域网内其他群里的聊天内容！这个实在太邪恶了。

上回抓包的时候，虽然看不到内容，但可以看到美术、策划在群里聊的无比欢乐。这回有喜感了。

STEP END 可略

看看时间，悲剧地发现整篇文章花了接近3个小时才写完。此刻我正踌躇要不要把代码发上来，但转念一想

最后那个STEP的发现实在让人蛋疼，所以还是算了。打算稍微封装下，然后使用这份代码在iptux 上改改包装

个界面，目的就算达成了。相信浏览完整篇文章，写出自己的代码不是什么大问题。

其实我大可以直接给结论，但是我依然乐于分享过程和思路。一来算是自我总结记录（每次拿起OD，总是快捷

键一路忘）；二来也给有心人一个指引。

最后，对这种东西还是有必要出个免责声明：根据本文章所造成的一切后果与文章作者无关。为了不糟蹋我这3个

小时的时间，转载麻烦注明出处。

PS，最后回顾下结论，其实发现这个解密非常非常简单。你说如果直接给卢本陶（飞秋作者）发封邮件，他会不

会直接告诉我？

Kevin Lynx 2011-01-23 21:01 发表评论

一段tricky codes：函数调用的那些底层细节

Kevin Lynx — Sun, 02 Jan 2011 08:34:00 GMT

有一天，被同事问到了下面这段代码，就简单分析了一下，发觉还有点意思：

__declspec(naked)
void call(void* pfn, )
{
    __asm
    {
        pop eax;
        add eax, 3;
        xchg dword ptr[esp], eax;
        push eax;
        ret;
    }
}

再看它的用法：

void print_str( const char *s )
{
printf( "%s\n", s );
}
call( print_str, "a string" );

call函数的大致作用，就是调用传递进去的函数print_str，并将参数"a string"传递给目标
函数。

但是它是怎么做到的呢？虽然call只有简单的几句汇编代码，但是却包含了很多函数在编译
器中的汇编层实现。要了解这段代码的意思，需要知道如下相关知识：

0、函数调用的实现中，编译器通过系统堆栈(ESP寄存器指向）传递参数；
1、C语言默认的函数调用规则(_cdecl)中，调用者从右往左将参数压入堆栈，并且调用者负
责堆栈平衡，也就是保证调用函数的前后，ESP不变；
2、汇编指令call本质上是先将返回地址，通常是该条指令的下一条指令压入堆栈，然后直
接跳转到目标位置；
3、汇编指令ret则是先从堆栈栈顶取出返回地址，然后跳转过去；
4、汇编指令add加上其操作数，貌似占3个字节长度；
5、在visual studio中，DEBUG模式下编译器会在我们的代码中插入各种检测代码，而
__declspec(naked)则是告诉编译器：别往这里添加代码。

了解了以上常识后，再看这段代码，其本质无非就是利用了这些规则，在代码段跳来跳去。
我们来逐步分析一下：

在调用call函数的地方，大概的代码为：

caller:
// 堆栈状态，从左往右分别表示栈顶至下
// ret_addr是call后的地址，即add esp, 8的位置
// a1, a2表示函数参数，callee_addr是这里的print_str
// stack: ret_addr, callee_addr, a1, a2,
call( print_str, "a string" );
add esp, 8 //清除参数传递所占用的堆栈空间，维持堆栈平衡
end_label //位于add后的指令，后面会提到

call:
// 此时堆栈stack: ret_addr, a1, a2
pop eax // eax = ret_addr; stack: callee_addr, a1, a2,
add eax, 3 // eax = end_label; stack: callee_addr, a1, a2,
xchg dword ptr[esp], eax // eax = callee_addr; stack: end_label, a1, a2,
push eax // stack: callee_addr, end_label, a1, a2,
ret // 取出callee_addr并跳转，也就跳转到print_str函数的入口，此时堆栈
// stack: end_label, a1, a2,

callee(print_str):

无视函数内容

ret // print_str返回，此时正常情况下，堆栈stack: end_label, a1, a2,
// 取出end_label并跳转，stack: a1, a2,

那么当callee结束时，则跳转回caller函数中。不过，如过你所见，此时堆栈中还保留着再
调用call函数时传入的参数：stack: a1, a2, ...，所以，DEBUG模式下，VS就会提示你堆
栈不平衡。这里简单的处理就是手动来进行堆栈平衡：

    call( print_str, "a string" );
    __asm
    {
        add esp, 4;
    }

传入了多少个参数，就得相应地改变esp的值。

话说距离上篇博客都有半年了，自己都不知道时间晃得如此之快。最近业余折腾了下android开发，
一不小心就跨年了。

Kevin Lynx 2011-01-02 16:34 发表评论

静态库中全局变量的初始化问题

Kevin Lynx — Sun, 17 Jan 2010 11:34:00 GMT

在我自己写的一个工厂类实现中，每个产品会注册创建接口到这个工厂类。工厂类使用这些
注册进来的创建接口来完成产品的创建。其结构大致如下：

product *factory::create( long product_type )
{
creator c = m_creators[product_type];
return c();
}

factory::instance().register( PRODUCT_A_TYPE, productA::create );
...
factory::instance().create( PRODUCT_A_TYPE );

这个很普通的工厂实现中，需要写上很多注册代码。每次添加新的产品种类时，也需要修改
这些的注册代码。而恰好，这些注册代码可能会被放在一个统一的地方。为了消除这个地方
，我使用了偶然间看到的里的做法：

const bool _local = factory::instance().register( PRODUCT_A_TYPE,...

也就是说，通过对全局常量_local的自动初始化，来自动完成对该产品的注册。

结果，因为这些代码全部被放置于一个静态库。最终的代码文件结构大致为：

lib
    - product_a.cpp : 定义了全局常量_local
    - product_a.h
    - factory.cpp
    - factory.h
exe
    - main.cpp

现在看起来世界很美，因为factory甚至不知道世界上还有个跟上层逻辑相关的product_a。
这种模块耦合几乎为0的结构让我窃喜。

悲剧的事情首先发生于，开VC调试器，发现打在product_a.cpp里的断点失效。就是那个总
是提示说没有为该文件加载调试符号。开始还不在意，以为又是代码和调试符号文件不匹配
的原因，折腾了好久，不得其果。

后来分析了下，发现这个调试提示，就像我开着调试器打开了一个非本工程的代码文件，而
断点就打在这个文件里一样。也就是说，VC把我product_a.cpp当成不是这个工程里的代码
文件。

按照这个思路写些实验代码，最终发现问题所在：VC链接器根本没链接进product_a.cpp里
的代码。表现出来的情况就是，该编译单元里的全局常量（全局变量一样）根本没有得到初
始化，因为我跟到factory::register并没有被调用到。为什么VC不链接这个编译单元对应
的目标文件？或者说，为什么VC不初始化这个全局常量？

原因就在于，product_a.cpp太独立了。一个在整个编译链接阶段都无法确定该文件是否被
使用的文件，VC就直接不链接了。相反，当在factory.cpp里写下类似代码：

void test()
{
product_a obj;
}

虽然说test函数不会被调用，一切情况也变得正常了。好了，不扯了，给最后我的结论：

1、如果静态库中某个编译单元在编译阶段被确认为它并没有被外部使用，那么当这个静态
库被链接进可执行文件时，链接器忽略掉该编译单元里的代码，那么，链接器自然也不会为
该编译单元里出现的全局变量常量生成初始化代码（关于这部分初始化代码可以阅读
一书）；
2、上面那条结论存在一种传染性，意思是，当可执行文件里的代码使用到静态库中文件A里
的代码，A里又有地方使用到B里的代码，那么B依然会被链接。这种依赖性，应该可以让编
译器在编译阶段就发现（显然，上面我举的例子里，factory只有在运行期间才会依赖到
product_a.cpp里的代码）

Kevin Lynx 2010-01-17 19:34 发表评论

自己写内存泄露检测库

Kevin Lynx — Fri, 23 Jan 2009 09:43:00 GMT

author: kevin lynx

这个内存泄露工具最基本的原理就是利用宏替换掉标准的malloc、free（暂不考虑其他内存分配函数，
如realloc、strdup），记录下每次内存分配和释放动作。因为宏的处理发生在预处理阶段，所以可以
很容易地用你自己的malloc函数替换掉标准的malloc。例如：

/* lib.h */
#define malloc my_malloc
#define free my_free

/* lib.c */
/* disable these macro in this compile unit */
#undef malloc
#undef free

static int count = 0;

void *my_malloc( size_t size )
{
    ++count;
    return malloc( size );
}

void my_free( void *a )
{
    --count;
    free( a );
}

要使用以上代码，用户在使用时就需要包含lib.h，从而可以使用宏将用户自己写的malloc替换
为my_mallo。当程序退出时，如果count大于0，那么可以肯定的是有内存泄露。当然，如果
count为负数，则很可能对同一个指针进行多次free。

但是以上代码的功能太局限了。一个真正的内存泄露检测库（工具），至少需要报告泄露的代码
文件、函数、行数等信息。当然，如果能报告调用堆栈，就更好了。不过这就依赖于具体的平台，
需要使用特定的系统接口才可以获取出。

要实现以上功能也很简单，只需要在每次调用malloc的时候，通过编译器预定义宏__FILE__、
__LINE__、__FUNCTION__(__func__)就可以得到文件名、函数、行号等信息。将这些信息保存
起来，然后在free的时候移除相应的信息即可。

最简单的实现方式，就是保存一个表，表里记录着每次分配内存的信息：

struct memRecord
{
    char file[MAX_FILE_NAME];
    char func[MAX_FUNC_NAME];
    size_t lineno;
    void *address;
    size_t size;
};

struct memRecord mem_record[MAX_RECORD];

但是，通过单单一个free函数的void*参数，如何获取出对应的分配记录呢？难道：

for( size_t i = 0; i < MAX_RECORD; ++ i )
{
    if( address == mem_record[i].address )
    {
        /* shit */
    }
}

虽然可行，但是很stupid。这里提供一个小技巧：

void *my_malloc( size_t size )
{
    void *a = malloc( size + sizeof( size_t ) );
    return (char*)a + sizeof( size_t );
}

void my_free( void *a )
{
    /* actually, 'a' is not the real address */
    char *p = ((char*)a - sizeof( size_t ) );
    free( p );
}

意思就是说，我多分配了4字节内存（sizeof( size_t ) ），用于保存这次分配记录在mem_record
中被保存的索引。在释放内存的时候，通过一些地址偏移计算，就可以获取出真正的系统malloc
返回的地址，从而安全释放（别给我说这里的计算存在平台和编译器的限制，没认真看文章的SB才说）。

另一个问题是，我们如何处理每次分配释放时，对于分配记录那个数据结构，也就是mem_record。
每一次free的时候，移除的记录可能位于mem_record的任何位置。一定时间后，mem_record内部
将出现很多漏洞（已经没用的数组位置）。解决这个问题最直接当然还是最stupid的方法，就是每次
free移除记录时重新整理一遍mem_record。如果你这样做了，那你的malloc/free比微软的还慢。

我的解决方法是：
size_t free_index[MAX_RECORD];
用于保存这些出现漏洞的index。每一次free移除记录时，就把这个记录对应的inex保存进来，表示
这个index指向的mem_record[]可用。每一次malloc的时候，先从这里取index，如果这里没有，那
可以直接从mem_record的末尾取。

具体细节就不阐述了，典型的空间换时间方法。整个库很简单，代码100来行。我也只进行过粗略的
测试。我肯定这100来行代码是有问题的，相信自己的代码存在问题是对bug的一种觉悟，哈哈哈。

这个东西只检测C语言的内存泄露，其实要检测C++的也很简单，只需要重载new和delete就可以了。

要放春节假了，在公司的最后几个小时实在无聊，才做了这个东西，前后花了1个多小时，写起来感觉
不错。

代码下载

Kevin Lynx 2009-01-23 17:43 发表评论

最近的两个问题：less for std::map，静态变量初始化顺序

Kevin Lynx — Tue, 11 Nov 2008 09:55:00 GMT

说下最近自己遇到的两个值得让人注意的问题。
其一是关于自己给std::map写less predicate，std::map第三个参数是一个典型的functor。map内部将使用
这个functor去判定两个元素是否相等，默认使用的是std::less。但是为什么传入的是一个判断第一个参数
小于第二个参数的functor，而不是一个判断两个参数是否相等的functor？按照STL文档的说法，当检查两
个参数没有小于也没有大于的关系时，就表示两个参数相等。不管怎样，我遇到了需要自己写这个functor
的需求，于是：

struct MyLess
{
    bool operator() ( long left, long right )
    {
        //...
    }
};

DEBUG模式下编译没问题，RELEASE模式下却出现C3848的错误。这就有点奇怪了，如果确实存在语法错误，
那么DEBUG和RELASE应该一样才对。查了下MSDN，C3848的错误是因为const限定符造成的，如：

const MyLess pr;
pr(); // C3848

于是，在operator()后加上const，就OK了。看了下VC std::map相关代码，以为是DEBUG和RELEASE使用了不
同的代码造成。但是我始终没找到不同点。另一方面，就STL内部的风格来看，应该不会把predicator处理
成const &之类的东西，全部是value形式的。奇怪了。

第二个问题，涉及到静态变量。这个东西给我的印象特别深刻，因为以前去一家外企应聘时被问到，当时
觉得那个LEADER特别厉害。回来后让我反思，是不是过多地关注了C++里的花哨，而漏掉了C里的朴素？导致
我至今对纯C存在偏好。

说正题，我现在有如下的文件关系：

// def.h
struct Obj
{
Obj()
{
ObjMgr::AddObj( id, this );
}
int id;
};

struct ObjMgr
{
static void AddObj( int id, Obj *t )
{
ObjTable[id] = t;
}
static std::map ObjTable;
};

static Obj _t;

// ObjMgr.cpp
#include "def.h"

static std::map::ObjMgr ObjTable;

// main.cpp
#include "def.h"

这里举的例子可能有点不恰当，我在一台没有编译器的机器上写的这篇文章。忽略掉这些旁支末节。我的意思，
就是想让Obj自己自动向ObjMgr里添加自己。我们都知道静态变量将在程序启动时被初始化，先于main执行之前。

上面代码有两个问题：

一、
代码没有按照我预期地执行，如果你按照我的意思做个测试，你的程序甚至在进main之前就crash了。我假定你
用的是VC，因为我没在其他编译器上试验过。问题就在于，Obj的构造依赖于ObjTable这个map对象。在调试过程
中我发现，虽然ObjTable拥有了内存空间，其this指针有效，但是，map对象并没有得到构造。我的意思是，Obj
的构造先于ObjTable构造（下几个断点即可轻易发现），那么在执行map::operator[]时，就出错了，因为这个时候
map里相关数据还没准备好。

那是否存在某种机制可以手动静态变量的初始化顺序呢？不知道。我最后怎样解决这个问题的？

二、
在还没有想到解决办法之前（不改变我的设计），我发现了这段代码的另一个问题：我在头文件里定义了静态
变量：static Obj _t; 这有什么问题？想想预编译这个过程即可知道，头文件在预编译阶段被文本展开到CPP
文件里，然后，ObjMgr.cpp和main.cpp文件里都将出现static Obj _t;代码。也就是说，ObjMgr.obj和main.obj
里都有一个文件静态变量_t。

看来，在头文件里放这个静态变量是肯定不对的。于是，我将_t移动到ObjMgr.cpp里：

// ObjMgr.cpp
#include "def.h"

static std::map::ObjMgr ObjTable;
static Obj _t;

按照这样的顺序定义后，_t的构造居然晚于ObjTable了。也就是说，放置于前面的变量定义，就意味着它将被
首先构造初始化。这样两个问题都解决了。

但是，谁能保证这一点特性？C标准文档里？还是VC编译器自己？

Kevin Lynx 2008-11-11 17:55 发表评论

让人无语的boost

Kevin Lynx — Wed, 15 Oct 2008 03:23:00 GMT

    关于BOOST，撞车，严重撞车。每一次都让我有点无语。
    第一次是我所谓的宏递归，其实就是一个macro library，有一天就不小心在BOOST的library list上
看到了这个东西。当然，BOOST很牛，别人的这个macro是真的library。但是，我们的需求撞车，我们的
实现手段撞车。于是下定决心下次想要实现个什么东西的时候，先去看看BOOST，可以省掉不少脑力。
    本来就没有做好，何必吃力不讨好？
    第二次，当我写下类似的模板代码时：

template <typename _Tp>
void func( _Tp t );

    我总要花掉几秒钟时间去决策func的参数是用_Tp&还是_Tp，也就是所谓的究竟是按值传送还是按引用
传送。如果按值传送，当_Tp为一个类时，复制的东西过多时，显然效率上过不去。作为func的实现者，良
心上更过不去。后来一想，STL的各种算法里到处都是按值传送，这样做总有它的理由吧？
    但是，这样做就是不够完美。
    于是想起了boost::ref。但是这个时候我并不知道boost::ref是个什么东西。我只是以前在各种地方
看到过这个东西。我还是决定自己实现一个。
    实现一个什么？考虑有：

template <typename _Tp>
void func( _Tp t );

而我这个时候要传递一个类对象过去CBaseObject obj。为了效率，我写下如下的代码：

    template <typename _Tp>
    class ref_wrapper
    {
    public:
        ref_wrapper( _Tp &p ) : _obj( &p ) { }
        operator _Tp& () { return *_obj; }
    private:
        _Tp *_obj;
    };

然后再使用func时，func( ref_wrapper( obj ) );这样，发生复制操作的最多就是这
个ref_wrapper，基本上也就是复制了一个指针，而不会复制整个obj。当然，这里可以写一个模板函数去
简化func的调用，如：

    template <typename _Tp>
    ref_wrapper<_Tp> ref( _Tp &t )
    {
        return ref_wrapper<_Tp>( t );
    }

    这样调用的时候就简单了：func( ref( obj ) );
    其实这就是boost的ref库，按照其官方文档，ref库就是：
    The Ref library is a small library that is useful for passing references to function
templates (algorithms) that would usually take copies of their arguments.

然后我就懵了。于是我不得不在kl_ref.h里写上check out boost::ref for more information的字眼。

    好，接下来说说第三次。
    第三次我遇到了这样一种需求，我需要一个容器，就像你知道的std::list。但是与std::list甚至STL
中所有容器都不同的是，这个容器里保存的东西具有不同的类型。
    这个时候我想起了tuple。我没有实现过tuple。大致上这个东西的实现原理就是利用类型递归来保存
数据，就像loki的type list。另一方面，tuple的尺寸似乎不能动态增长。
    于是我有了自己撇脚的实现：

    class base_type
    {
        virtual ~base_type() { }
    };
    template <typename _Tp>
    class var_wrapper
    {
    public:
        var_wrapper( const _Tp &t ) : _t( t )  {}
        operator _Tp& () { return _t; }
    private:
        _Tp _t;
    };

    class var_list
    {
    public:
        typedef std::vector<base_type*> TypeList;
    public:

        template <typename _Tp>
        void add( const _Tp &t )
        {
            var_wrapper<_Tp> *var = new var_wrapper<_Tp>( t );
            _list.push_back( t );
        }

        template <typename _Tp>
        _Tp &get( size_t index )
        {
            base_type *base = _list.at( index );
            typedef var_wrapper<_Tp> var_type;
            var_type *var = static_cast<var_type*>( base );
            return *var;
        }
    private:
        TypeList _list;
    };

说白了，我就是利用一个包装类将各种类型包装其中，然后利用基类指针实现统一管理。直白地说，我
对这个组件不满意。让人诟病的是，get接口是类型不安全的。例如：

    int a;
    CBaseObject obj;
    var_list my_var_list;
    my_var_list.add<int>( a );
    my_var_list.add<CBaseObject>( obj );

取出值的时候：

int b = my_var_list.get<int>( 0 );
CBaseObject cobj = my_var_list.get<CBaseObject>( 1 );

但是，因为get没有类型检查，即使你：

CBaseObject cobj = my_var_list.get<CBaseObject>( 0 );

也不会出错，编译器不会给予你警告。
事情到此结束，这个类型不安全的组件只能依靠程序员自己的谨慎去生存。

    然后，又是一个不小心，我在boost里看到了any。boost::any库同boost::ref库一样，是一个tiny
library。几十行的代码一目了然。
    boost::any有一个placeholder基类，有一个template holder派生类，然后有
一个提供给外部的any类。看了代码后有一种让我喷血的感觉。其实现原理和我自己的完全一致。
    比较而言，我觉得我的var_list撇脚到了极致。因为我封装了容器，而这显然是没必要的，并且限制
了其使用范围。而boost::any则是仅仅封装了类型。
    数据转换方面，boost::any提供了any_cast和unsafe_any_cast。unsafe_any_cast和我这里用的转换
差不多，也就是我说的类型不安全。而他的any_cast呢？则是用到了typeid，多了次类型检查而已。
    没办法，看来var_list需要被删掉，直接搬boost::any过来吧，同样地check out boost::any for more
information...
    现在看来，boost真的很强大。我感觉再怎么偏门的需求，都能在boost里找到个实现。痛定思痛，决定
把boost doc长期开着。

Kevin Lynx 2008-10-15 11:23 发表评论

代码自动生成-宏递归思想

Kevin Lynx — Wed, 20 Aug 2008 09:48:00 GMT

Macro Recursion
author: Kevin Lynx

Preface

本文可能是<代码自动生成-宏带来的奇技淫巧>的续写。我尽力阐述如何让宏递归（或者说重复）地有规律地产生一
些符号，而让我们少写很多重复代码，也许这些代码只有那么一点点的不同。将这项小技巧用于底层库的编写，会让代码
看起来干净不少，同时文件尺寸也会骤然下降。

Problem

如果你曾经写过functor，那么你肯定对某些代码进行粘贴复制然后修改。更让人郁闷的是，这些代码基本是一样的。
例如，一个典型的functor可能为：

    template <typename Prototype>
    class functor;
    template <typename R, typename P1>
    class functor<R(P1)>;
    template <typename R, typename P1, typename P2>
    class functor<R(P1,P2)>;

    //好，接下去你可能厌烦了，可能会复制一个带有两个参数的functor，然后修改为处理3个参数的。
    这只是一个很简单的问题。宏不是c++里的东西，本文自然也不是讨论各种花哨的模板技术的。如果我之前那篇关于
宏的文章只是让你去分析问题以及更深层次地认识宏，那么现在我将分享我的这部分思想给你。
    关于上面的问题，我们期待得到这样的解决方案：

template <typename R, DEF_PARAM( 2 )>
class functor<R( DEF_ARG( 2 ) )>;

那么，它将自动生成：

template <typename R, typename P1, typename P2>
class functor<R(P1,P2)>;

也就是说，DEF_PARAM(n)这个宏将根据n值自动生成一串符号，例如DEF_PARAM(2)就生成typename P1, typename P2。
同样，DEF_ARG(n)也会根据参数生成类似于P1,P2,...,Pn的符号串。

思考

仔细思考下，我们可以看出DEF_PARAM和DEF_ARG这样的宏具有一种递归的特性（其实说成重复可能更合适）：每次展
开的内容基本一样，不断调用自身直到遇到终止条件。
那么，我们的目标锁定于，用宏来实现递归。

Pre-Implement

在开始之前，我需要告诉你一些基本的东西：
在阅读一个宏时，你最好按照预处理的处理方式去逐个展开。当我说到展开时，我的意思是把宏替换为宏体。预处理器
展开宏的过程大致为：如果宏参数也是个宏，那么先将宏参数全部展开，再展开该宏；这个时候会扫描展开后的宏，如果
遇到其他宏，则继续展开。例如有一下宏：

#define PI 3.14
#define MUL_PI( n ) n * PI
#define TWO 2

    当我们写下MUL_PI( TWO )时，预处理发现MUL_PI的参数TWO 是个宏，那么先将TWO展开得到2，然后将2放进宏体展开
得到 2 * PI；预处理器对 2 * PI 进行扫描，发现还有宏PI，于是对PI做展开，得到 2 * 3.14。这个过程是递归的。
    但是也有例外，如果MUL_PI对宏参数进行了#或者##，那么该宏参数不会被展开。（参见以前那篇文章吧）
    任何时候，你可以通过以下宏去查看某个宏展开后的样子，可以方便你调试你的宏：

#define TO_STRING( x ) TO_STRING1( x )
#define TO_STRING1( x ) #x

（为什么要写个TO_STRING1，因为这是为了让x充分展开，避免上面提到的那个例外）

其他规则我会在文中需要的地方提出来。
实现

就像大部分介绍递归函数时候给的例子，这里我也将阶乘作为例子。考虑如下典型的阶乘函数：

    int fac( int n )
    {
        if( n == 1 ) return 1;
        return n * fac( n - 1 );
    }

其核心部分在于 n * fac( n - 1 )，我们假设我们的宏也可以写成这样的的形式：

#define FAC( n ) n * FAC( n - 1 )

    但是这样的宏是有问题的：
    当宏被展开时，如果遇到了自身，那么将被处理为一般符号，例如展开FAC( 3 )时，会遇到 FAC( 2 )，那么就把FAC
( 2 )中的FAC当成了一搬符号。
    这样的限制注定了我们无法让宏真正地调用自身来实现递归。于是，我们不得不写下以下丑陋的符号，从而去模拟递
归的每一次符号调用：

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##(n-1)( n - 1 )
#define FAC_3( n ) n * FAC_##(n-1)( n - 1 )

    这系列宏有点别扭（如果你足够细心），因为我们明显知道FAC_2返回的将是2，而FAC_3返回的当时6。我们这里只是
模拟，同样，这使得我们可以把FAC_1作为递归的终止条件。
    我们的预想是，当调用FAC_3时，它把n-1的值2合并到FAC_中，从而调用FAC_2，以此类推。
    但是这依然有问题，编译器会提示‘找不到符号FAC_’。导致这个问题的原因在于：宏展开只是单纯的字符替换，是我们
想太多了，预处理器并不会去计算( n - 1 )的值是多少，也就是我们无法得到FAC_2这个宏。

所以，FAC_3( 3 ) 会被初次替换为 3 * FAC_(3-1)( 3 - 1 )。这个时候编译器就把FAC_当成了一个普通符号。我们可以
自己定义个FAC_来证明这一点：

#define FAC_( n ) T

那么，FAC_3( 3 )就被替换为 3 * T(3-1)( 3 - 1 )。

解决这个问题的办法关键在于，让预处理器自动计算出( n - 1 )。记住，我们解决问题的唯一办法是：字符替换。
所以，我们可以写下如下代码：

#define DEC_1 0
#define DEC_2 1
#define DEC_3 2

#define DEC( n ) DEC_##n

通过，DEC( n )这个宏，我们可以获取到一个( n -1 )的数。例如，DEC( 3 )被替换为 DEC_3，继续替换为 2。

于是，我们新的FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##DEC( n )( n - 1 )
#define FAC_3( n ) n * FAC_##DEC( n )( n - 1 )

不好意思，这样依然是不正确的！预处理器直接把FAC_和DEC( n )连接成符号了，而不是单个地先处理他们，最后再
合并他们。

OK，先解决这个问题：先处理FAC_和DEC( n )，再合并他们，而不是先合并他们。要解决这个问题，可以通过第三个宏
来实现：

#define CHR( x, y ) x##y

作为连接两个符号为一个符号的宏，这个宏显然是不正确的，因为宏展开还有个规则：如果宏体对宏参数使用了#或##，
那么宏参数不会被展开，也就是说：如果CHR( FAC_, DEC( 3 ) 那么得到的只会是 FAC_DEC( 3 )。通常情况下我们是
再写个宏：

#define CHR( x, y ) CHR1( x, y )
#define CHR1( x, y ) x##y

从而可以保证在正式连接x和y前，x和y都被完全展开。

这个时候，我们的FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( n - 1 )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( n - 1 )

结果呢？结果还是有问题。= =
我们假设CHR( FAC_, DEC( n ) )已经真的按我们预想展开为 FAC_2了，那么FAC_3( 3 )会被展开为什么呢？
被展开为 3 * FAC_2( 3 - 1 )。这是错误的，传给 FAC_2 的参数是 3 - 1就意味着错误。我们又臆想预处理器会
帮我们计算 3 - 1的结果了。我们必须保证传给 FAC_2的参数是个数字2。解决这个问题的办法就是通过DEC(n)宏。

于是，FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) )

这个时候，FAC_3( 3 )将会被替换为：3*2*1。这就是我们要的结果。

In practice

以上只是向你展示一个过程，用宏去计算阶乘，就像用模板去计算阶乘（模板元编程）一样，只是一个用于展示的东西，
没有什么实际价值。接下来我们开始有实际的工作，完成之前的预想：

template <typename R, typename P1, typename P2, typename P3>
class functor<R (P1, P2, P3)>

直接:

template <typename R, PARAM( 3 )>
class functor<R (ARG( 3 ))>

先考虑PARAM宏，该宏的任务就是生成类似于：typename P1, typename P2, typename P3这样的符号。我们假象它每一次
递归都生成 typename Pn, 的字符串，那么当他递归完时，可能就生成typename P1, typename P2, typename P3, 结果
多了个逗号，也许最后一次结果不该有逗号。

ARG宏和PARAM宏本质上相同，只是重复的符号不是typename Pn，而是Pn。

最直接想到的是：

#define PARAM_1( n ) typename P##n
#define PARAM_2( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n
#define PARAM_3( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n

结果我们得到了个错误的展开结果：
typename PDEC( 2 ),typename PDEC( 3 ),typename P3

这个问题出在：PARAM_3( 3 )当替换为 PARAM_2( DEC( n ) )时，因为PARAM_2(n)宏对于宏参数n使用了##，也就是那个
typename P##n，所以这里不会把 DEC( n )展开，而是直接接到P后面。所以就成了typename PDEC( 3 )。

为了消除这个问题，我们改进PARAM为：

#define TYPE( n ) ,typename P##n
#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )

之所以加入TYPE(n)，是因为 ,typename P##n 这个宏本身存在逗号，将其直接用于宏体会出现问题。

于是，我们得到了正确的结果。

其实，PARAM系列宏宏体基本是一样的，除了终止条件那个宏，为什么我们要写这么多呢？理由在于宏体不能自己调用
自己，所以才有了PARAM_3, PARAM_2。

我们可以将上面的一系列宏抽象化，使其具有可复用性：

#define PARAM( n ) ,typename P##n
#define PARAM_END typename P

#define ARG( n ) ,P##n
#define ARG_END P

#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )

#define REPEAT_1( n, f, e ) CHR( e, n )
#define REPEAT_2( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) )
#define REPEAT_3( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) )

#define DEF_PARAM( n ) REPEAT_##n( n, PARAM, PARAM_END )
#define DEF_ARG( n ) REPEAT_##n( n, ARG, ARG_END )

我们创建了可重用的REPEAT系列宏，用于创建诸如typename P1, typename P2, typename P3或者P1,P2,P3之类的符号，
通过更上层的DEF_PARAM(n)和DEF_ARG(n)，就可以直接创建出我们上面所需要的符号串，例如：

DEF_PARAM( 3 ) 就得到 typename P1, typename P2, typename P3
DEF_ARG( 3 ) 就得到 P1, P2, P3

More in practice

下载中提供了我使用这个宏递归技术写的lua_binder(如果你看过<实现自己的LUA绑定器-一个模板编程挑战 >)，你
可以与上一个版本做一下比较，代码少了很多。
同样，我希望你也能获取这种宏递归的思想。

相关下载

使用宏递归的lua_binder

Kevin Lynx 2008-08-20 17:48 发表评论