我遇到了一个 EXC_BAD_ACCESS，其中包含一段处理数据序列化的代码。该代码仅在设备 (iPhone) 上失败，在模拟器上不会。它还仅在某些数据类型上失败。

这是重现问题的测试代码:

template <typename T>
void test_alignment() {
    // allocate memory and record the original address
    unsigned char *origin;
    unsigned char *tmp = (unsigned char*)malloc(sizeof(unsigned short) + sizeof(T));
    origin = tmp;

    // push data with size of 2 bytes
    *((unsigned short*)tmp) = 1;
    tmp += sizeof(unsigned short);

    // attempt to push data of type T
    *((T*)tmp) = (T)1;

    // free the memory
    free(origin);
}

static void test_alignments() {
    test_alignment<bool>();
    test_alignment<wchar_t>();
    test_alignment<short>();
    test_alignment<int>();
    test_alignment<long>();
    test_alignment<long long>();   // fails on iPhone device
    test_alignment<float>();
    test_alignment<double>();      // fails on iPhone device
    test_alignment<long double>(); // fails on iPhone device
    test_alignment<void*>();
}

猜测一定是内存对齐的问题，我决定要彻底了解这个问题。根据我对内存对齐的(有限的)理解，当 tmp 提前 2 个字节时，对于对齐大于 2 个字节的数据类型，它会变得不对齐:

    tmp += sizeof(unsigned short);

但是测试代码对于 int 和其他代码执行正常!它仅对 long long、double 和 long double 失败。

检查每种数据类型的大小和对齐方式后发现，失败的数据类型是具有不同 sizeof 和 __alignof 值的数据类型:

iPhone 4:
bool           sizeof = 1 alignof = 1
wchar_t        sizeof = 4 alignof = 4
short int      sizeof = 2 alignof = 2
int            sizeof = 4 alignof = 4
long int       sizeof = 4 alignof = 4
long long int  sizeof = 8 alignof = 4 // 8 <> 4
float          sizeof = 4 alignof = 4
double         sizeof = 8 alignof = 4 // 8 <> 4
long double    sizeof = 8 alignof = 4 // 8 <> 4
void*          sizeof = 4 alignof = 4

iPhone Simulator on Mac OS X 10.6:
bool           sizeof = 1 alignof = 1
wchar_t        sizeof = 4 alignof = 4
short int      sizeof = 2 alignof = 2
int            sizeof = 4 alignof = 4
long int       sizeof = 4 alignof = 4
long long int  sizeof = 8 alignof = 8
float          sizeof = 4 alignof = 4
double         sizeof = 8 alignof = 8
long double    sizeof = 16 alignof = 16
void*          sizeof = 4 alignof = 4

(这些是从 "C++ data alignment and portability" 运行打印函数的结果)

谁能告诉我是什么导致了错误？差异真的是 EXC_BAD_ACCESS 的原因吗？如果是这样，通过什么机制？

最佳答案

这实际上很烦人，但对于我们这些在 x86 之前的世界中购买的人来说并不那么意外:-)

想到的唯一原因(这是纯粹的推测)是编译器正在“修复”您的代码以确保数据类型正确对齐，但是 sizeof/alignof 不匹配会导致问题。我似乎记得 ARM6 架构放宽了某些数据类型的一些规则，但从来没有好好看看它，因为决定使用不同的 CPU。

(更新:这实际上是由寄存器设置(因此可能是软件)控制的，所以我想即使是现代 CPU 仍然会提示不对齐)。

我要做的第一件事是查看生成的程序集，看看编译器是否正在填充您的短消息以对齐下一个(实际)数据类型(这会令人印象深刻)或(更有可能)预在写入之前填充实际数据类型。

其次，找出我认为是 iPhone4 中使用的内核的 Cortex A8 的实际对齐要求是什么。

两种可能的解决方案:

1/您可能必须将每种类型转换为 char 数组并一次传输一个字符 - 这有望避免对齐问题，但可能会对性能产生影响。使用 memcpy 可能是最好的，因为它无疑会被编码以利用底层 CPU(例如在可能的情况下传输四字节 block ，在开始和结束时使用一字节 block ) .

2/对于那些不想紧跟在 short 之后的数据类型，在 short 之后添加足够的填充以确保它们正确对齐。例如，像这样的东西:

tmp += sizeof(unsigned short);
tmp = (tmp + sizeof(T)) % alignof(T);

在尝试存储值之前，应该将 tmp 推进到下一个正确对齐的位置。

稍后您需要做同样的事情来读取它(我假设短表示正在存储的数据，因此您可以知道它是什么数据类型)。

将 OP 的最终解决方案放在答案中以确保完整性(这样人们就不必检查评论):

首先，程序集(在 Xcode 上，Run menu > Debugger Display > Source and Disassembly)显示在处理 8 字节数据时使用了 STMIA 指令(即, long long), 而不是 STR 指令。

接下来《ARM体系结构引用手册ARMv7-A》(Cortex A8对应的体系结构)的“A3.2.1 Unaligned data access”一节指出STMIA不支持unaligned data access while STR 可以(取决于某些注册表设置)。

所以，问题是 long long 的大小和错位。

至于解决方案，作为开始，一次一个字符是可行的。

关于c++ - 为什么这个 EXC_BAD_ACCESS 发生在 long long 而不是 int 上？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3243146/