1

我曾经gdb附加到一个进程。我试图弄清楚为什么它会陷入无限循环，以及它在做什么。我发出命令backtrace并gdb得到以下结果：

#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意思？另外，为了确定：第二列中的数字是内存中函数的地址吗？

4

2 回答 2

2

PLT 是过程链接表。请参阅此处的文档。这用于延迟加载函数引用。

是不是一直卡在这里？这里纯粹是猜想，但如果是这样，那可能表明该函数仍未解决。例如，如果未加载预期的库。

是的，十六进制数字通常表示压入堆栈的指令指针的值。您可以使用命令验证这一点l * <address>，告诉 GDB 列出该地址处的代码行。或者只是使用f <frame#>命令切换到该堆栈帧。

尝试查看/proc/<pid>/maps（此过程的 PID 在哪里<pid>）并查看您期望的库是否talloc_free已加载。

于 2013-04-10T23:12:13.053 回答
0

我很确定“@plt”是名称修饰的一部分。是的，第二列是您的地址。所以你现在可以输入“完成”，如果 gdb 没有让你在短时间内回到提示符，那么这意味着你的无限循环发生在talloc 的 free 中。这可能是talloc 库中的一个错误（我从未使用过），或者更有可能是您损坏了堆。您经常会发现使用 glibc 时，它会检测堆损坏并给您一个漂亮的崩溃消息。

我建议你在 valgrind 中运行你的程序——这是一种快速检测内存错误的好方法。

于 2013-04-10T23:06:56.400 回答