跟大神请教

我们是win32的服务器 然后用的cocos的客户端 cocos编译的win32程序 跟android两个不同平台的程序 

然后那创建人物的时候 会下发一个int64 也就是longlong的字段 win32没问题 但是android就会出现崩溃 。。

大神：“win32 跟 arm……字序一样吗？”

那又如何检查自序那 ？

大神：”我能想到的最快最土的办法就是，把一个 int64 看成 char[8]，然后打印出来“

崩溃如图

fatal siganl 7（SIGBUS）at 

哦，SIGBUS……
大神
这个可能不是 pack 的问题
大神
pack 也无法保证
大神
如果是 SIGBUS 的话，我理解系统可能希望 sBuf+index-sizeof ( __int64 ) 这个地址是一个对齐在 64 位的地址

如果 sBuf 里全都是 64 位数据的话，问题倒也不大，但是如果你还有 GetInt32，GetChar 之类的接口，不按照 8 字节对齐的协议去修改 index 的话，可能有些 cpu 就受不了了——我知道 MIPS 有这说法，ARM 还真不了解

那只能避免使用int64？

大神

 

没关系，一般 RISC 都还会有 unaligned 指令集的吧……

大神

没关系，一般 RISC 都还会有 unaligned 指令集的吧……

__int64 GetInt64 ( char* sBuf, int& index, unsigned int nBufferLen )
{
          __int64 n;
index += sizeof ( __int64 );
          memcpy(&n, sBuf+index-sizeof ( __int64 ), sizeof(__int64));
return n;
};  虽然没有考虑字序 Byte Order 的问题 这么处理 希望 memcpy 中的指令对操作数的要求可以是 unaligned 的 

看了log.txt得出结论  不过异常原因基本上八九不离十了：code 1 (BUS_ADRALN)，我猜 ADRALN 就是 Address Alignment 之类的缩写，肯定是这个出问题了

fault addr 776a2db3 这句很要命，这个地址充其量就对齐在 1 字节上吧，或者说根本没对齐……

大神

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html

你可以抽空看看这个，这是 ARM 编译器对未对齐指针的优化，可能会造成干扰

 

 是的，我知道在 RISC 的 memcpy 实现中，最常见的做法就是用 unaligned 指令处理头尾非对齐的地址，然后用 aligned 指令处理中间对齐的部分——对齐的操作数性能会好很多 

 

 你可以瞅瞅 lib 库的编译优化选项，如果有任何选项有“把memcpy/memmov/memset优化为intrinsic”的话，那可能调用 memcpy 还是会崩，因为编译器会直接把 memcpy 展开成 load/store 指令的，不会有任何函数调用。这种情况下，可以尝试弄个函数指针指向 memcpy，然后你再去 call 函数指针——不知道这样弄的话，会不会把编译器弄傻，它就不去做 intrinsic 优化了 

 

ps 总之最后按照大神的思路算是把问题解决了 虽然我还是云里雾里的