Question

情境：

有一个复杂的软件很难手动启动。我所做的是创建一个python脚本来启动可执行文件并附加 gdb 进行调试。

流程启动脚本：

确保设置环境变量。
确保将本地构建目录添加到环境的LD_LIBRARY_PATH变量。
将当前工作目录更改为可执行文件期望的位置（不是我的设计）
使用配置文件启动可执行文件唯一的命令行选项
将可执行文件的输出通过管道传输到第二个日志记录进程
记住可执行文件的PID，然后启动＆amp;将gdb附加到正在运行的可执行文件。

该脚本有效，但有一点需要注意。 ctrl-c不会中断debugee并将控制权返回给gdb。因此，如果我“继续”没有活动断点，我再也无法停止进程，必须从另一个shell中杀死/中断。 BTW，运行“kill -s SIGINT＆lt; pid＆gt;”其中＆lt; pid＆gt;是调试对象的pid确实让我回到了gdb的提示......但是这样做是非常烦人的

起初我认为Python正在抓取SIGINT信号，但事实并非如此，因为我设置了信号处理程序将信号转发给debugee并且无法解决问题。

我已经尝试了各种配置到python脚本（调用os.spawn *而不是子进程等）似乎无论如何，如果python启动了子进程，SIGINT（ctrl-c）信号不要被路由到gdb或子进程。

目前的思路

这可能与需要a有关 debugee＆amp;的独立进程组ID gdb ......对此有任何信任吗？
SELinux可能存在的错误？

信息：

gdb 6.8
Python 2.5.2（Python 2.6.1中存在的问题）
SELinux Environment（向进程发送信号的错误？）

我考虑的替代方案：

设置.gdbinit文件以执行脚本执行的操作，环境变量和当前工作目录是此方法的问题。
手动启动可执行文件并附加gdb（yuck）

问题： 如何自动启动/调试大型项目？

更新我已经尝试了下面的Nicholas Riley的例子，在家里的Macintosh上，他们都允许cntl-c工作到不同程度，在生产盒子上（我现在认为可能正在运行SELinux）他们没有...

Answer 1

您可以尝试忽略它，而不是将信号从Python转发到调试对象。以下对我有用：

import signal
signal.signal(signal.SIGINT, signal.SIG_IGN)

import subprocess
cat = subprocess.Popen(['cat'])
subprocess.call(['gdb', '--pid=%d' % cat.pid])

有了这个，我能够在GDB内部反复进行^ C并且没有问题地中断调试对象，但是我确实看到了一些奇怪的行为。

顺便说一句，将信号转发到目标进程时也没有问题。

import subprocess
cat = subprocess.Popen(['cat'])

import signal, os
signal.signal(signal.SIGINT,
              lambda signum, frame: os.kill(cat.pid, signum))

subprocess.call(['gdb', '--pid=%d' % cat.pid])

那么，也许你的情况还会发生其他事情？如果您发布了一些破解的代码，可能会有所帮助。

Answer 2

你的评论指出你正在用腻子砸...你有控制权吗？使用openssh，您可能希望添加-T选项，我不知道putty是如何以您使用它的方式执行此操作。

另外：您可以尝试使用cygwin的ssh而不是putty。

Answer 3

如果您已经设置了当前脚本来执行此操作，但是在自动执行部分操作时遇到问题，也许您可以抓住期望并使用它来提供设置，然后退回到交互模式，期望启动处理。然后你仍然可以让你的ctrl-c中断。

您如何自动启动/调试大型项目？

3 个答案: