gdb 全局变量被修改_排错经历:全局变量被多次析构

这篇博客记录了一个C++服务器程序在退出时因全局变量异常析构导致的崩溃问题。通过gdb调试,发现一个std::string全局变量在main函数退出后的析构过程中引发崩溃。作者详细描述了使用gdb跟踪内存释放、定位问题代码的步骤,并揭示了由于动态链接库中全局变量冲突和exit函数hook导致的问题本质。最后,提供了一个简化版的代码示例以重现问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们team有一套C++写的server程序,最近发现它在每次退出的时候会崩溃,core dump文件的栈如下:

(gdb) bt

#0  0x0000003ea4e32925 in raise () from /lib64/libc.so.6

#1  0x0000003ea4e34105 in abort () from /lib64/libc.so.6

#2  0x0000003ea4e70837 in __libc_message () from /lib64/libc.so.6

#3  0x0000003ea4e76166 in malloc_printerr () from /lib64/libc.so.6

#4  0x0000003ea729d4c9 in std::basic_string, std::allocator >::~basic_string() ()

from /usr/lib64/libstdc++.so.6

#5  0x0000003ea4e35e22 in exit () from /lib64/libc.so.6

#6  0x0000003ea4e1ed24 in __libc_start_main () from /lib64/libc.so.6

#7  0x0000000000400629 in _start ()

下面介绍一下我是如何找到出问题的代码。

请注意,因为编译器优化的缘故,这个栈是不完整的。安装完调试符号后,栈应该是这样:

(gdb) bt

#0  0x0000003ea4e32925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

#1  0x0000003ea4e34105 in abort () at abort.c:92

#2  0x0000003ea4e70837 in __libc_message (do_abort=2, fmt=0x3ea4f58aa0 “*** glibc detected *** %s: %s: 0x%s ***\n”)

at ../sysdeps/unix/sysv/linux/libc_fatal.c:198

#3  0x0000003ea4e76166 in malloc_printerr (action=3, str=0x3ea4f58d48 “double free or corruption (fasttop)”,

ptr=) at malloc.c:6336

#4  0x0000003ea729d4c9 in _M_dispose (this=, __in_chrg=)

at /usr/src/debug/gcc-4.4.7-20120601/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.h:236

#5  std::basic_string, std::allocator >::~basic_string (this=,

_

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值