如何使用gdb调试SIGSEGV段错误及相关问题排查

问题1：如何获取栈帧#0中??对应的相关信息？ #

栈帧#0显示??是因为当前程序缺少调试符号，或栈结构被破坏、地址所属的动态库未加载符号表，可按以下步骤操作：

1. 重新编译目标程序时添加-g参数保留调试符号，例如编译命令改为g++ -g test.cpp -o sementation_fault_test，避免编译时加-s参数剥离符号。
2. 带符号重新运行程序复现段错误后，在gdb中执行info sharedlibrary查看加载的动态库地址范围，确认0xc0101fd0是否属于某个动态库的地址段，若属于则安装对应动态库的带调试符号版本即可识别符号。
3. 如果是栈结构被破坏导致的符号无法识别，配合后续内存检测工具定位栈篡改的位置后，即可还原栈帧信息。

问题2：日志中的地址是否为虚拟内存地址？每次运行该地址都不相同的原因是什么？有什么方法可以获知该地址对应的内容？ #

• 日志中的地址均为虚拟内存地址，Linux用户态程序所有可访问的地址都是操作系统通过页表映射后的虚拟地址，和实际物理地址无直接对应关系。
• 每次运行地址不同是因为操作系统默认开启了地址空间布局随机化（ASLR），该机制会随机偏移程序栈、堆、动态库的加载地址，用于避免恶意攻击利用固定内存地址执行漏洞代码。
• 获知地址对应内容的方法：
  • 在gdb中执行x/10i 0xc0101fd0可查看该地址起始的10条汇编指令，执行info symbol 0xc0101fd0可尝试匹配地址对应的符号名称，执行x/s 0xc0101fd0可查看该地址是否指向可读字符串。
  • 程序运行时执行cat /proc/<对应进程PID>/maps可查看进程的完整内存映射表，匹配地址所属的文件/内存段，再通过objdump、readelf等工具分析对应文件的内容即可。

问题3：还有哪些可以进一步定位该问题的可行方案？ #

• 编译时追加参数-fstack-protector-all -Wall -O0，关闭编译优化同时开启栈溢出检测、全量警告，编译阶段即可提前发现部分潜在的代码逻辑问题。
• 使用valgrind工具运行程序，执行命令valgrind ./sementation_fault_test，可直接定位野指针访问、数组越界、释放后使用等绝大多数导致段错误的内存问题。
• 重点排查Test::segmentationFaultTest()函数内的指针操作、数组访问、动态内存申请释放逻辑，可在该函数的各个执行节点加打印日志，逐步缩小触发段错误的代码范围。
• 调试阶段可临时关闭ASLR方便定位，执行命令echo 0 | sudo tee /proc/sys/kernel/randomize_va_space即可关闭地址随机化，调试结束后执行echo 2 | sudo tee /proc/sys/kernel/randomize_va_space恢复默认配置。
• 若确认是栈结构被破坏导致的回溯异常，可在gdb中针对栈上的返回地址设置观察点，监控是哪行代码篡改了栈数据，直接定位问题代码行。

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