3

在 CentOS 6.6 上编程时，我删除了一个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

FreeBSDgcore有一个可选参数“ executable ”，看起来很有希望（好像我可以指定要使用的二进制文件不是/proc/15659/exe），但这对我没有用，因为Linuxgcore没有任何这样的参数。

有什么解决方法吗？还是我只需要重新启动该过程（使用重新创建的可执行文件）并等待我正在跟踪的错误重现自身？

4

1 回答 1

4

尽管有 的输出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把我带回了这条路，我的担心显然没有根据，GDB 能够core.15659为我创造一个可爱的人。

于 2015-03-12T22:13:55.220 回答