关于iOS的问题

1 现象：开发调试时没有问题，提交到AppStore后下载，第一次可以运行，第二次开始闪退，手机开启飞行模式就不会闪退。

分析：网络部分是另起一个线程后台执行的，其中还涉及读取sqlite代码，最开始怀疑是不是第一次产生了数据，第二次数据库中有数据，读取时有问题，后来还真发现了一个可能为null指针的问题，但是这块修改了，闪退依旧。

然后想着打日志排查，但是release模式不好排查，只好将日志写入文件，看执行到哪里崩溃，就这样一步步加日志，最后发现是执行到一个从网络字节流读取int64_t的时候崩溃的，代码如下：

var = (int64_t)ntohll( *(uint64_t*)buf );

其中ntohll是我写的一个从网络序转换到主机序的一个辅助函数（因为系统只提供了ntohs和ntohl两个版本），在进入ntohll之前就崩溃了，这又让我怀疑是不是函数调用栈爆了，因为在这一步之前还可以执行，这一步唯一的操作就是调用ntohll，需要一个压栈操作，虽然一般只有频繁递归的情况才有可能出现，但是发现把函数调用展开成代码还是会挂。

然后我又尝试把变量地址都打印出来，因为buf虽然是个指针，但是它的初始位置是一个数组，并且可以保证没有走出这个数组，各种百思不得姐。

最后终于发现，是内存对齐引发的bug，也就是说，如果读取一个整型变量，不从某个对齐的地址（目前arm是4字节对齐）开始读取，那么就会引发一个硬件的exception（称之为EXC_ARM_DA_ALIGN）。

那么为什么在调试时没有引发这个bug呢？个人猜测是iOS在这个模式下捕获了这个异常，并且将其转换为两次内存请求了。

解决办法：编译器会将所有声明的整型变量（或者多字节变量，例如float、double）对齐到4的倍数，所以我们可以先memcpy到变量，再对变量操作。代码如下：

memcpy( &var, buf, sizeof(var) ); var = (int64_t)ntohll( var );

不过memcpy也可能有问题，依赖于memcpy的实现（里面不能出现未对齐的强转指针），更保险的方法是自己写个循环进行单个字节的赋值。

参考文献：

[1]  www.keil.com/support/man/docs/ca/ca_ap_byte_alignment.htm

[2] http://stackoverflow.com/questions/3439128/non-8-byte-aligned-memory-access-causes-memory-access-violation-on-iphone-3gs-wi