linux - 在 Linux 下,是否可以 gcore 一个可执行文件已被删除的进程?

标签 linux debugging gdb gcore

在 CentOS 6.6 上编程时,我删除了一个在屏幕 session 中运行的可执行文件(糟糕,make clean)。

现在,无关紧要,我想通过 gcore 进程来调试一些东西。我已重建可执行文件,但 gcore 不接受替换后的文件。它知道原始文件已被删除,不会让我转储核心。

# gcore 15659
core.YGsoec:4: Error in sourced command file:
/home/dev/bin/daemon/destinyd (deleted): No such file or directory.
gcore: failed to create core.15659

# ls -l /proc/15659/exe
lrwxrwxrwx. 1 root root 0 Mar 12 21:33 /proc/15659/exe -> /home/dev/bin/daemon/destinyd (deleted)

# ln -s /proc/15659/exe /home/dev/bin/daemon/destinyd
ln: creating symbolic link `/home/dev/bin/daemon/destinyd': File exists

# rm /proc/15659/exe
rm: remove symbolic link `/proc/15659/exe'? y
rm: cannot remove `/proc/15659/exe': Permission denied

FreeBSD's gcore有一个可选参数“executable”,它看起来很有前途(好像我可以指定一个不是 /proc/15659/exe 的二进制文件来使用),但这没有用对我来说是Linux's gcore没有任何这样的论点。

有什么解决方法吗?或者我是否只需要重新启动进程(使用重新创建的可执行文件)并等待我正在跟踪的错误重现?

最佳答案

尽管 ls -l/proc/15659/exe 的输出,原始可执行文件实际上仍然可以通过该路径获得。

因此,我不仅能够使用简单的 cp 恢复原始文件(尽管这不足以恢复链接并让 gcore 工作),但我能够使用此路径作为可执行文件将 GDB 附加到进程:

# gdb -p 15659 /proc/15659/exe

然后运行“generate-core-file”命令,然后运行“detach”。

然后,我可以自由地根据需要检查核心文件:

# gdb /proc/15659/exe core.15659

事实上,我忘记了 GDB 生成核心文件的能力,而且我对实际将 GDB 附加到进程感到焦虑,因为时机非常重要:在准确的正确时间生成核心文件以捕获该错误。

但是nos steered me back onto this path而且,我的担心显然是多余的,GDB 能够为我生成一个可爱的 core.15659

关于linux - 在 Linux 下,是否可以 gcore 一个可执行文件已被删除的进程?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29021096/

相关文章:

过去 X 分钟的 Linux CPU 负载

linux - 用于从目录中获取文件到命令行的 Shell 脚本

linux - 多实例上的 Gdb

.net - 是否有像 DbgCLR.exe 这样的工具可用于调试 .NET Framework 4.0 程序集

c - 使用gdb--仍然找不到malloc错误

c++ - gdb 奇怪的行为( [next] 在 block 代码上跳回几行)

java - Linux,top 命令,为什么 "data"值和 jvm -xmx 参数不相等?

c++ - 在 Ubuntu 中使用 Visual Studio 运行 C++ 文件时出错

algorithm - 处理各种日志记录级别

c - GDB 在 Linux 中带有 coredump 文件