VS2013 - C++碰到一个诡异的内存访问错误,很怀疑是 VS 的问题，要被逼疯了···求提点 T_T

先交代下环境吧。个人在做一个游戏的小功能（算是练习吧），用的cocos2d-x引擎，前些天从3.6版本升级到3.7（引擎内部好像有内存管理相关的改动），出现了一个奇怪的bug。
平台是win7 64 + VS 2013 community updater 5。工程target都是x86 machine

下午再去xcode下搭建一个试试去，看看是不是ide的问题。

就是这个
https://github.com/acros/cocos2dx_qte

问题是这样的:
cocos2d-x里有个类叫Scene，我派生了class MainGameScene : public Scene,派生类中成员变量就加了两个RefPtr指针mUiLayer和mGameLayer。（注：RefPtr是cocos2d-x一个轻量级的shared_ptr类似存在）

通过VS的工具输出，确认Scene和MainGameScene的内存布局如下（这里就给出类末尾一段内容）：
1> 708 | | _physicsWorld
1> 712 | | _navMesh
1> 716 | | _navMeshDebugCamera
1> | +---
1> 720 | ?$RefPtr@VLayer@cocos2d@@ mGameLayer
1> 724 | ?$RefPtr@VLayer@cocos2d@@ mUiLayer
1> +---

_navMesh和_navMeshDebugCamera是Scene类最后两个成员变量。
720偏移之前都是Scene的，这个表是正确的。

这个工程里面，cocos2d-x引擎部分是导出成一个dll的，然后主项目去加载它，MainGameScene这个类是在我自己的项目里面创建的。然而将一个指向MainGameScene的Scene*类型传到引擎代码中时，对于scene*内存的读取就发生了诡异的变化！
见下图：

可以看到：scene*的地址是0x060BBC88，加上前面计算的720偏移量，0x060BBF58地址应该是mGameLayer的地址，实际这时通过scene*访问到_navMesh变量时，取到的是mGameLayer地址！！！

图中下方窗口还可以看到，我加了个类型转换后再访问，地址就对了····>_<

(*((qte.exe!cocos2d::Scene*)(&(*((qte.exe!MainGameScene*)(scene))))))._navMesh
和&(scene)->_navMesh 取到的地址差 8 ??????

看起来虚表并没有被破坏掉，而且编译器计算类内成员offset时，这个offset怎么会算错，个人完全没头绪啊····(类成员地址不是类地址+offset计算的吗？)

注：scene*指针只在项目dll工程里面访问才会出现这个错误的偏移计算，我之前想过是不是项目配置错了，但问题是，什么东西配置错了会导致这种错误呢？！

XiXiLocked

2015-07-26 17:26:01 +08:00

你看直接读navMesh是有值的，但是指针转换之后读的navMesh是NULL，说明转的有问题
信口开河一把，
scene的内存布局是
scene::vptr
scene::members ...
MainGameScene的里面有并不继承于scene的虚函数，所以他的虚表插在了前面，于是布局大概是这样
scene:vptr
MainGameScene::vptr <--这里多了虚表指针的8
scene::members ...
MainGameScene::members ...
上面说的没有把握，但是你可以看看之前的成员变量的地址验证一下

lcsky

2015-07-26 19:05:38 +08:00

可能是遗漏了某些概念，我随便拍拍脑袋能想到相关的可能有：
1、struct、class成员的默认内存对齐方式(#pragma pack)
2、不清楚C++其实是没有ABI兼容性的

后面这个问题会导致不同的C++编译器、编译器版本、甚至只是不同的编译参数生成的二进制代码不兼容。你看系统库都是纯C接口的发现没有？因为纯C有函数调用的ABI兼容性标准：stdcall、cdecl、fastcall。而C++是彻底没有ABI兼容性的，能“差不多对上”只是运气好，或者编译器版本、参数完全一样。

所以重点恐怕是检查你dll和主程序的编译参数有何区别