您有一个bug,请注意查收!

发表于2017-06-04
评论0 1.4k浏览


这次的标题有点搞怪,工程师最怕的就是“Bug”,希望没有吓到大家。。。

这次起点放低,写点比较基础的,相信大家都能看懂。从曾经遇到的一个Server端代码的bug说起。


背景

几年前的某一段时间,我负责给一款游戏做跨平台移植,准备开发一款技术Demo。由于这款游戏是早些年端游繁盛时代的产品,所以Client和Server都是C++开发。我们先把Client由PC端移植到Android,在解决了所有的问题之后我们开始进行IOS的移植。对这些平台了解的人会知道他们都是类Unix系统,所以移植起来会比较容易。不幸的是我在IOS平台下遇到了一个奇怪的崩溃。。。


调试及解决

分析崩溃栈发现堆栈信息无法准确反应崩溃原因,而且崩溃时机不定(跟游戏逻辑相关)。有经验的人可能已经猜到了,发生了内存越界。通过反复重现,可确定内存越界发生在Server发送某数据包给Client,Client接收之后解析的过程中。这种问题在平时的工作中算是比较难搞的,因为平时调试所依赖的堆栈信息已经靠不住了。


背景知识:

为了保持数据打包和解析的一致,Server端的数据包打包代码以及Client的解析代码使用了相同的数据包结构定义。

由于头文件指导编译期生成代码的内存布局,所以按理说Client和Server两端的数据在内存中的大小应该一致。


2015年2月苹果要求所有新提交审核的应用都必须支持64位。2015年6月1日苹果App Store中所有应用更新都必须支持64位。所以应苹果要求我们把IOS平台代码编译为64位,但是Android和PC始终保持编译为32位程序。测试发现Android和PC平台程序跑起来完全没有问题,所以猜测可能是由于IOS编译为64位程序导致的问题。


科普一下,一般为了保持最小的数据传输量,网络数据包的定义都按一字节对齐来使数据紧密地排列(关于数据对齐在IOS上有个很奇怪的问题,我相信这个问题很少有人知道,我准备在后面的文章中跟大家分享一下)。所以可以通过数据结构的成员定义直接算出数据包占用内存的大小。

拿上面的代码为例,这个数据包大小应该为4 + 2 + 1 + 5 * 1 + 4 = 16 Byte。


调试:

通过输出所有发送包和解析包的大小有如下发现:

1.Client做某数据包解析的时候比Server端实际发送的多读取了4 Byte。然而检查数据包定义并未发现有64位系统与32位系统占内存大小不同的数据类型被使用。

2.Server实际发送的数据大小比数据包定义多出了4 Byte,IOS客户端解析的时候比数据包定义多解析了8 Byte。也就是同一个数据包,32位环境下多了4 Byte,64位环境下多了8 Byte。


问题分析到这里,基本就可以断定:类的定义中存在指针,并且这个指针是隐藏的,它就是指向虚函数表的指针。


虚函数表指针在编译期将类的大小增加了几个字节。在Server端由于是32位程序,指针按照4 Byte编译。IOS端是64位程序,指针按8 Byte编译。这就导致了IOS端做数据解析的时候比实际Server发送的多解析了4 Byte,发生了内存越界。


仔细检查代码发现这个数据包的定义是这样的(由于这是几年前的经历,所以这里我写了个小例子,原来的代码已经不在了):

在我们发送的这个数据包的基类中有一个虚函数定义。由于虚函数的引入,在类对象的头部要增加一个虚函数表指针指向类的虚函数表。C++的动态绑定是由虚函数表来实现的,详细的关于虚函数表的知识我这里不多讲了,不了解的朋友可以去看看《More Effective C++》。

对于虚函数表感兴趣的朋友定义一个类Derived对象,然后在VS中调试一下。我们可以在Watch窗口中观察一个类的内存布局。

上图中可以看到在对象的内存区域的头部有一个名为“_vfptr”的变量,这就是传说中的虚函数表指针,也就是这次bug的元凶。


解决:

检查所有数据包结构定义代码,发现这种带有虚函数定义的数据包类大量存在。分析为什么使用虚函数,然后修改代码,删掉虚函数定义。编译运行,问题解决了。


问题总结:

这个问题在Client与Server同为32位或64位程序的时候不会发生,因为Client和Server两边对这个隐含的指针的大小的解析是一致的(4/8 Byte),但是这样的代码并不是没有问题的。首先这里隐藏着一枚我们没有意识到的炸弹存在,说不定哪一天我们就踩上了。再者如果是为移动应用开发的代码,大量的数据包定义使用虚函数,导致每一次网络通信,每一个数据包都多发送4/8 Byte。这样累积起来对于用户流量的浪费也不容小视。这不是一个严谨的工程师应该犯的错误。


写在最后

解决这个小问题花费了我基本一下午的时间。关于虚函数表的概念很多时候我们会在面试中遇到,但是真正理解为什么会有这样的面试题存在的人很少。甚至有人还跟我说:“你这个问题太底层,我们平时写代码都用不到;我已经写了4、5年C++了,从来没有遇到过关于虚函数表的问题。”


我一直坚持认为把技术的基础打好,才是避免出现各类问题的最根本办法。经常遇到挂着各种头衔的“XXX工程师”,聊起技术给我一种很不舒服的感觉,好像他的代码不是跑在计算机上,他对计算机一无所知,却对XXX领域了如执掌。有人可能觉得这是某一领域的专家,但是我认为计算机的领域分的没有那么细。无论用什么语言写的代码,最终都要跑到硬件上,而且数据结构及算法是通用的;无论使用何种图形API或者某一款图形引擎,图形学的基本原理是不变的;无论做什么方向的开发我们都要接触现代计算机操作系统,而各个系统涉及到的基本理论又是一致的。所以我认为在成为“XXX工程师”之前,应该先把自己定位为优秀的“计算机工程师”。


我发布在这里的文章都是转至我的微信订阅号,如果你想及时获得最新发布的文章,可以关注我的微信订阅号。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引