我使用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是什么意思？另外，只是为了确定：第二列中的数字是内存中函数的地址吗？
答案 0 :(得分：2)
PLT是程序链接表。见the documentation here。这用于延迟加载函数引用。
总是卡在这里吗？纯猜想在这里，但如果是这样，这可能表明该功能仍未解决。例如，如果未加载预期的库。
是的，十六进制数通常表示推入堆栈的指令指针的值。您可以使用l * <address>命令对此进行验证，以告知GDB列出该地址的代码行。或者只需使用f <frame#>命令切换到该堆栈帧。
尝试查看/proc/<pid>/maps（其中<pid>是此过程的PID）并查看您希望talloc_free所在的库是否已加载。
答案 1 :(得分：0)
我很确定“@plt”是名称整理的一部分。是的，第二列是你的地址。所以你现在可以输入“完成”，如果gdb没有带你回到短时间的提示，那么这意味着你的无限循环正在发生在talloc的免费中。这可能是talloc库中的一个错误（我从未使用过），或者更可能是你的堆损坏了。您经常会发现，在使用glibc时，它会检测到堆损坏并给您一个漂亮的崩溃消息。
我建议您在valgrind中运行程序 - 这是一种快速检测内存错误的好方法。