在CentOS 6.6上编程时,我在屏幕会话中运行时删除了一个可执行文件(呼呼,清理干净).

现在,无关紧要的是,我想让整个过程调试一些东西.我已经重建了可执行文件,但是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.