提供未剥离版本后GDB仍无法显示剥离核心文件的符号

核心原因分析 #

1. GDB无法显示函数参数信息 #

从config.log的编译参数可以看到，C++代码的编译参数CXXFLAGS缺少-g选项，仅在CFLAGS（C代码编译参数）中添加了-g。这会导致C++部分的调试信息不完整：

• 函数名能显示是因为链接阶段保留了全局符号，但函数内部的参数、局部变量等调试信息并未生成，所以info args会提示"No symbol table info available"。
• 同时启用了-O2优化，编译器会对代码进行重排、内联、变量消除等操作，即使有-g也会让调试信息失真，进一步影响参数和变量的查看。

2. 省略可执行文件参数后无法显示函数名 #

core文件仅记录进程崩溃时的内存状态和寄存器信息，不包含完整的符号表。GDB需要依赖可执行文件来将内存地址映射为函数名、变量名等符号，因此省略可执行文件路径后，无法解析调用栈中的地址对应的函数名。

3. 循环调用与SIGSEGV的关联 #

虽然栈空间未溢出，但completed和startdelivery的交替循环调用（多达200+次）说明存在逻辑上的循环调用链。这种情况下，很可能是某次调用中某个指针被错误修改（比如空指针、野指针），或者某个状态变量异常，最终触发了SIGSEGV，而非栈溢出。

解决建议 #

• 重新编译程序补充调试信息：修改编译配置，确保CXXFLAGS添加-g选项，同时暂时移除-O2优化（避免编译优化干扰调试），重新执行configure && make生成带完整调试信息的可执行文件，再用GDB加载core文件调试，此时应该能查看函数参数和局部变量。
• 排查循环调用逻辑：检查msgq::completed和msgq::startdelivery的代码，确认是否存在未正确终止的循环调用条件，比如回调逻辑没有设置退出机制，导致反复调用直到触发内存访问错误。

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