解释gdb回溯
解释gdb回溯
提问于 2013-04-11 05:36:42
我使用gdb附加到一个进程。我正在试图弄清楚为什么它会陷入无限循环，以及它在做什么。我在gdb中发出命令backtrace并得到以下结果：
#0 0x000000000041cf30 in _talloc_free@plt ()
#1 0x0000000000452320 in winbindd_reinit_after_fork ()
#2 0x00000000004524e6 in fork_domain_child ()
#3 0x0000000000453585 in wb_child_request_trigger ()
#4 0x000000381d2048e2 in tevent_common_loop_immediate () from /lib64/libtevent.so.0
#5 0x00007fbed6b98e17 in run_events_poll () from /lib64/libsmbconf.so.0
#6 0x00007fbed6b9922e in s3_event_loop_once () from /lib64/libsmbconf.so.0
#7 0x000000381d204060 in _tevent_loop_once () from /lib64/libtevent.so.0
#8 0x000000000042049a in main ()我的问题是:第一行中的@符号是什么意思？我知道_talloc_free是一个函数，但是@plt是什么意思呢？另外，只是为了确保:第二列中的数字是函数在内存中的地址吗？
回答 2
Stack Overflow用户
发布于 2013-04-11 07:12:13
PLT是过程链接表。参见the documentation here。这用于函数引用的延迟加载。
它总是卡在这里吗？这里纯粹是猜测，但如果是这样的话，这可能表明该函数仍未解析。例如，如果没有加载预期的库。
是的，十六进制数字通常表示压入堆栈的指令指针的值。您可以使用l * <address>命令来验证这一点，告诉GDB列出该地址的代码行。或者直接使用f <frame#>命令切换到该堆栈帧。
尝试查看/proc/<pid>/maps (其中<pid>是此进程的PID )，并查看是否加载了预期talloc_free所在的库。
Stack Overflow用户
发布于 2013-04-11 07:06:56
我很确定"@plt“是名字mangling的一部分。是的，第二列是你的地址。所以你现在可以输入"finish“，如果gdb没有在短时间内返回一个提示符，那么这意味着你的无限循环正在talloc的free中发生。这可能是talloc库中的一个bug (我从未使用过它)，或者更有可能的是，你已经损坏了你的堆。您经常会发现，在使用glibc时，它会检测到堆损坏，并给出一个很好的崩溃消息。
我建议您在valgrind中运行您的程序--这是一种快速检测内存错误的好方法。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/15936880
复制相关文章
相似问题
腾讯云开发者
