一个GCC优化引发的百忙一场

2014年6月25日 19:17 阅读 1895

好吧, 头一次试用下长微博....

白忙活了近2个小时,不吐不快:

一切要从今天下午5点左右说起, 调试一个扩展, 用valgrind(valgrind-3.8.1

)做例行检查, 很不幸的valgrind报告invalid read:

valgrind

db attach上去以后, 发现报告错误的地方是:

PHP NG中, 使用了新的字符串结构来保存字符串, 也就是zend_string:

而排插了半天, 我确认这个op是经过正常初始化的, 那问题出在哪里呢?

首先op是一个长度为1的字符串"0", 我突然想起来, 之前我们做了个很"精细"的优化, 因为对于上面的结构体, 在64位的系统上, sizeof它, 由于padding, 实际上会得到大于8 + 8 + 4 + 1(21) 的大小(8 + 8 + 8 = 24).

所以我们不会使用

str = malloc(sizeof(str) + len + 1)

来为一个长度为len的字符串申请内存. 而是会使用类似:

str = malloc ((int)((str*)0)->val) + len + 1)

的方式来为一个字符串申请内存, 所以对于"0", 我们实际上分配的内存是22bytes.

但, 又会有什么问题呢?

It's always easier to check than guess :)

于是让我们再次db attach上去, disassmble下看看具体是什么原因:

恩, 问题就出在f3b5这行, GCC读取了0x10(%rdx)位置上的一个word大小的数据, %rdx此时是zend_string op的指针, 而0x10偏移是str->len.

GCC优化很聪明的把

if (str->len == 1 && str->val[0] == '0')

优化成了和一个数据0x3000000001比较的一条指令....

于是, 如上面所说, 因为这个str只有22个bytes, 当尝试从16偏移处尝试读取8个字节的时候, 我们其实多读了str结构体外面的3个字节...... 于是就invalid read了

问题清楚了, GCC聪明的优化, 引起的一个无害的报告............ 于是, 白忙活了.... (当然, 最好还是修复掉, 我现在打算的修复就是, 最小也要分配一个24bytes).

体验感受: 长微博不能内嵌Code, CTRL + Z回撤很坑爹, 其他的感觉还不错 :)

PHP Stylite