1. 指针初始化与空指针检查
审查要点
- 未初始化指针：指针变量声明后未显式初始化，可能指向随机内存地址。
- 空指针解引用：对
NULL或未赋值的指针进行访问操作。
风险分析
未初始化的指针在解引用时会触发不可预测的内存访问，而空指针解引用则是SIGSEGV的直接诱因。例如，函数返回指针时未验证有效性，或结构体成员指针未初始化即被使用。
审查建议
- 检查所有指针变量是否在声明时初始化为
NULL，或在分配内存后立即赋值。 - 在解引用指针前，显式检查其是否为
NULL（例如通过if (ptr != NULL)）。 - 避免将指针作为函数返回值时隐含有效性假设，需在文档中明确说明调用方责任。
2. 动态内存分配与释放匹配
审查要点
- 内存泄漏：分配的内存未被释放，导致资源耗尽。
- 重复释放：对同一块内存多次调用
free或delete。 - 释放后访问：访问已被释放的内存区域（悬垂指针）。
风险分析
内存管理不一致会破坏堆结构的完整性。例如，在异常处理路径中遗漏释放逻辑，或错误地释放非动态分配的内存（如栈变量）。
审查建议
- 确认每个
malloc/new均有对应的free/delete，且释放逻辑在所有代码路径（包括异常）中均被执行。 - 释放指针后立即将其置为
NULL，避免后续误用。 - 使用RAII（资源获取即初始化）模式，将内存生命周期与对象生命周期绑定（如C++中的智能指针）。
3. 数组与缓冲区边界检查
审查要点
- 越界访问：写入或读取数组时超出其声明长度。
- 缓冲区溢出：向固定大小的缓冲区写入超出容量的数据。
风险分析
数组越界会覆盖相邻内存区域，可能破坏关键数据结构或返回非法地址。例如，字符串拷贝未检查目标缓冲区大小，或循环条件错误导致数组索引溢出。
审查建议
- 使用安全替代函数（如
strncpy替代strcpy），并显式指定目标缓冲区大小。 - 在循环中访问数组时，验证索引是否在
[0, length-1]范围内。 - 启用编译器选项（如GCC的
-D_FORTIFY_SOURCE=2）在运行时检测缓冲区溢出。
4. 函数返回值有效性验证
审查要点
- 忽略返回值：未检查可能返回错误或无效值的函数（如内存分配、文件操作）。
- 错误传播：未将底层函数的错误状态传递给上层调用者。
风险分析
许多系统调用和库函数在失败时返回特殊值（如NULL或-1）。若未验证返回值，后续操作可能基于无效数据执行。例如，fopen失败后直接读取文件指针。
审查建议
- 对所有可能失败的函数调用添加返回值检查，并根据错误类型采取恢复或终止措施。
- 设计统一的错误处理机制（如返回错误码或抛出异常），避免错误状态被静默忽略。
- 在文档中明确标注函数的返回值含义及调用方责任。
5. 多线程数据访问同步
审查要点
- 竞态条件：多个线程同时读写共享数据导致状态不一致。
- 死锁：锁的获取顺序不当引发线程阻塞。
风险分析
在多线程环境中，未同步的内存访问可能引发数据损坏或SIGSEGV。例如，一个线程释放内存后，另一个线程仍尝试访问该区域。
审查建议
- 识别所有共享变量和资源，使用互斥锁（
mutex）或读写锁（rwlock）保护访问。 - 遵循锁的获取顺序规则，避免嵌套锁导致的死锁。
- 考虑使用无锁数据结构或原子操作（如C++的
std::atomic）减少同步开销。
6. 类型转换安全性
审查要点
- 强制类型转换：绕过编译器类型检查的显式转换（如C风格强制转换）。
- 不兼容指针转换：将不同类型指针相互转换（如
int*转char*后越界访问）。
风险分析
不安全的类型转换会破坏类型系统，导致内存布局误解。例如，将结构体指针强制转换为整数指针后写入，可能覆盖非预期内存。
审查建议
- 优先使用C++的
static_cast、dynamic_cast等安全转换方式。 - 避免在指针类型间进行无意义的转换，确保转换后的操作符合内存布局逻辑。
- 对二进制数据操作（如网络协议解析）使用显式序列化/反序列化函数，而非直接指针转换。
7. 资源生命周期管理
审查要点
- 资源泄漏：未关闭文件、网络连接或释放锁等。
- 生命周期冲突：资源在仍被使用时被提前释放。
风险分析
资源管理不当会导致系统资源耗尽或非法访问。例如，文件描述符泄漏后达到系统限制，或线程未释放锁导致其他线程永久阻塞。
审查建议
- 采用RAII模式管理资源（如C++的
std::fstream自动关闭文件）。 - 在对象析构函数中显式释放所有持有资源，确保异常安全。
- 使用智能指针或自定义管理类封装资源，避免手动管理复杂性。
8. 第三方库与API使用规范
审查要点
- 版本兼容性：未验证库版本与代码的兼容性。
- 参数有效性：向库函数传递非法参数（如负数长度、未初始化缓冲区）。
风险分析
第三方库的内部实现可能隐藏SIGSEGV风险。例如，旧版库存在已知缓冲区溢出漏洞，或新版本修改了函数签名导致参数错位。
审查建议
- 明确指定依赖库的版本范围，并在构建系统中固定版本。
- 查阅库文档，验证所有函数调用的参数范围和约束条件。
- 对库返回的错误码或异常进行完整处理，避免传播未捕获的异常。
9. 系统调用与硬件交互
审查要点
- 权限不足：尝试访问无权限的系统资源（如只读内存写入）。
- 硬件限制：未考虑系统或硬件的特定约束（如内存对齐要求）。
风险分析
直接系统调用或硬件操作需严格遵循平台规范。例如，在ARM架构上未对齐的内存访问会触发硬件异常，而非简单的性能下降。
审查建议
- 查阅系统手册，确认所有系统调用的参数要求和错误返回值。
- 对硬件相关操作（如DMA缓冲区分配）使用平台提供的专用接口。
- 在跨平台代码中通过宏或条件编译处理架构差异（如内存对齐宏
alignas）。
10. 调试与日志完整性
审查要点
- 日志缺失：关键操作未记录状态，导致崩溃后无法定位原因。
- 调试信息残留：发布版本中包含调试符号或断言检查。
风险分析
完善的日志是诊断SIGSEGV的重要依据。例如，日志中未记录指针分配地址，导致无法从Core Dump中匹配崩溃位置。
审查建议
- 在关键路径（如内存分配、文件操作）中添加日志，记录操作类型、参数和返回值。
- 使用分级日志系统（如DEBUG/INFO/ERROR），确保发布版本可关闭详细日志。
- 在发布前移除所有调试断言（如
assert），或替换为生产环境可用的错误处理逻辑。
结论
避免SIGSEGV的核心在于构建防御性编程思维，通过代码审查将风险控制前移。上述10个审查项覆盖了从指针操作到系统交互的全流程，开发团队可根据项目特点调整优先级。例如，高并发服务需重点审查线程同步，而嵌入式系统需关注硬件约束。最终目标是通过系统化检查，将内存错误从运行时异常转化为编译期或代码审查阶段的可预防问题。
