读取5GB XML文件触发Segmentation fault，如何排查该问题？

栈回溯相关问题解答 #

• #0确实是程序崩溃前执行的最新指令，栈回溯的编号按调用栈从栈顶到栈底排序，编号越小对应的执行时机越晚。
• 地址显示??是因为GDB无法匹配该内存地址对应的调试符号，常见原因包括：
  • 该地址属于无调试符号的第三方依赖库或系统库
  • 程序发生栈溢出，栈上存储的返回地址被异常数据覆盖，导致GDB回溯到了不属于任何合法函数的非法内存地址
  • 运行的程序是剥离了符号表的发布版本，没有保留函数名等调试信息

内存扩容有效性判断 #

更换更大内存的机器大概率无法解决该问题，原因如下：

1. 你提供的ulimit -a输出中，内存相关限制（最大内存、虚拟内存）均为无限制，单纯内存不足会触发系统OOM杀手终止进程，不会产生段错误
2. 栈回溯显示你使用SAX方式解析XML，该模式不会一次性加载整个5GB文件到内存，对内存容量的要求远低于DOM解析
3. 内存不足导致的崩溃通常会出现在malloc、mmap等内存分配函数中，和当前栈回溯停在gettimeofday的特征不符

补充排查所需信息 #

你可以收集以下信息进一步定位问题：

• 运行的软件名称、版本号，是否为自行编译的版本
• 程序运行环境的操作系统版本、CPU架构
• 用大小远小于5GB的合法XML测试文件运行程序，确认小文件场景下能否正常执行，排除程序本身的逻辑错误
• 若为自行编译的程序，重新编译时添加-g编译选项保留调试符号，再用GDB复现问题获取更完整的栈回溯信息
• 验证待读取的5GB XML文件是否存在格式损坏、编码错误等问题

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