加个变量，程序崩了

前述

大家在平常的编程过程应该会碰到各种奇葩的问题吧，反正我最近是碰到了一次，再此跟大家分享一下。事情的原因是我在程序中增加了一个变量，然后就会导致程序每次都会进入异常。

示例代码

我将代码简化了，使用两个模块来演示这个问题。第一个模块是Dev模块。

下面是Dev模块的头文件，Dev结构体中有一个数组。

#include 
#include 

typedef struct {
 int a_[100];
 char b_;
}Dev;

void DevInit(Dev *c_this);

下面是Dev模块的源文件代码，里面只有一个memset。

#include "Dev.h"

void DevInit(Dev *c_this) {  
 memset(c_this, 0, sizeof(Dev));
}

第二个模块是DevManager，相关数据结构如下：

#include "Dev.h"

#pragma pack(1)

typedef struct {
 Dev uart_;
 char num_; // Adding this variable causes a crash
 Dev iic_;
}DevManage;

#pragma pack()

DevManage dev_manage;

void DevManagerInit(void) {
 DevManage *c_this = &dev_manage;
 
 memset(c_this, 0, sizeof(DevManage));
 
 DevInit(&c_this->uart_);
 DevInit(&c_this->iic_);
}

DevManage结构体包含uart以及iic设备，以及我新加入的一个num_变量，由于新增了num_变量以及与之相关的业务会导致每次调试目标板都会进入异常。

尝试解决异常问题

根据调试情况看，每次都会出现异常，说明是个小问题。就怕偶尔出现异常，不容易复现。

思路应该非常清晰，出现异常时候查看LR寄存器的值，LR寄存器主要有两个功能。

1. 保存子程序返回地址。使用BL或BLX时，跳转指令自动把返回地址放入r14中
2. 当异常发生时，异常模式的R14用来保存异常返回地址

根据LR寄存器的值，从而定位到是执行DevInit(&c_this->iic_)函数中的memset导致的。

第一反应是DevInit中传入的对象可能为空，操作了非法内存才导致的错误。于是又重新调试了一遍，发现DevInit中对象的地址并不为空，而且就是等于实体对象中设备的地址。

这一刻我陷入了深深的自我怀疑，memset难道不是这样用的？难道不是传入一个地址，清0，然后sizeof(DevManage)就完事了？

我这代码怎么会出错，memset就是这样用的，天王老子来我也是对的，这样的心理是不是也深度还原了碰到问题时的你们。

如果是你，该如何继续...

救命稻草

有人说，汇编是最后的救命稻草。那我也尝试抓住这根稻草，出现问题时如下图:

问题主要出现红色箭头指向的这一行，经过查询资料得知_aeabi_memclr4是一个用于ARM嵌入式系统的函数，用于将内存区域清零。函数名中的"_a"表示该函数符合ARM嵌入式应用二进制接口（Embedded Application Binary Interface，EABI）规范。在调用_aeabi_memclr4时，需要确保传入的内存地址是四字节对齐的。再看图片中的对象地址为0x200001BD，刚好比四字节对齐地址0x200001BC多了一个字节。

再回头看DevManage对象，这里使用了伪指令#pragma pack(1)让内存分配进行单字节对齐。因为Dev对象是按照四字节对齐的，紧接着引入了新的成员num_占用一个字节。所以导致iic_对象的地址相对于未增加变量之前的地址偏移了一个字节，导致不是四字节对齐的了，从而引发了错误。

就示例中的代码而言，只需要把强制DevManage对象单字节对齐的功能删除即可解决问题，因为默认情况下是四字节对齐的。

成员分配

由于#pragma pack(1)具有作用域限制，这里其实只是对num_变量做了单字节对齐的限制，而并没有对Dev对象的内存分配起到限制作用，Dev对象仍然是按照4字节对齐的(默认值)，所以Dev对象的所占用的长度一定是101*4=404字节。而整个DevManager对象的大小就101 * 4 + 1 + 101 * 4 = 809字节,成员分配如下图所示。

最后

到最后在抛出一个问题，对于上述的代码在vscode中使用gcc编译执行为何没有问题？