读取二进制文件触发Segmentation fault (core dumped)问题排查

1. 结构体内存对齐不匹配 #

写入和读取端的结构体内存对齐规则不一致是这类问题的高发原因。比如写入代码用了#pragma pack(1)取消对齐，读取端却默认按4/8字节对齐，会导致结构体实际占用字节数不匹配。小文件时偏移误差小可能没触发问题，大文件累积到一定程度就会读取到错误的内存区域，触发段错误。

• 检查两端的结构体定义，确保对齐设置完全一致，包括编译选项中的对齐参数。

2. 文件读取偏移计算错误 #

即便你没发现索引越界，大文件下的累积偏移误差也可能搞砸文件位置：

• 验证每次读取后的文件偏移是否符合预期：每个时间戳+N个结构体的总字节数必须等于sizeof(timestamp) + N * sizeof(particle)，用ftell检查当前位置是否和计算值一致。
• 别用feof当循环终止条件，应该判断fread的返回值是否等于预期读取的元素数。大文件下feof的判断有延迟，容易导致多读取一次，触发内存访问错误。

3. 堆内存分配溢出 #

calloc分配内存时，如果N过大，N * sizeof(particle)可能超过size_t的范围，导致实际分配的内存远小于需求，后续写入时直接越界访问堆外内存：

• 检查内存分配代码，添加溢出检查，比如用断言：assert(N <= SIZE_MAX / sizeof(particle));，提前发现分配参数的问题。

4. 结构体含指针类型的错误写入 #

如果particle结构体里有指针成员（比如char* data），写入时用fwrite直接写入指针地址，读取后这个地址在当前进程中是无效的，访问时就会触发段错误——刚好memmove这类函数会因为非法指针报错：

• 检查结构体定义，若有指针成员，写入时要序列化指针指向的数据，而不是指针本身；读取时要重新分配内存并复制数据。

5. 实用调试技巧 #

• 用valgrind跑读取程序，它能精准定位内存越界、非法指针的位置，比gdb的栈回溯更直观。
• 在读取循环中加日志，打印接近崩溃前的索引、文件偏移、结构体成员值，对比写入时的原始数据，看是否出现偏移错位。
• 把写入和读取逻辑放到同一个程序里测试，排除跨编译环境的差异，快速复现问题。

内容的提问来源于stack exchange，提问作者TalJo