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

Scenario:

There is a complex piece of software that is annoying to launch by hand. What I've done is to create a python script to launch the executable and attach gdb for debugging.

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

The process launching script:

流程启动脚本:

ensures an environment variable is set.

确保设置环境变量。

ensures a local build directory gets added to the environment's LD_LIBRARY_PATH variable.

确保将本地构建目录添加到环境的LD_LIBRARY_PATH变量中。

changes the current working directory to where the executable expects to be (not my design)

将当前工作目录更改为可执行文件期望的位置(不是我的设计)

launches the executable with a config file the only command line option

使用配置文件启动可执行文件唯一的命令行选项

pipes the output from the executable to a second logging process

将可执行文件的输出传递给第二个日志记录进程

remembers PID of executable, then launches & attaches gdb to running executable.

记住可执行文件的PID,然后启动并将gdb附加到正在运行的可执行文件。

The script works, with one caveat. ctrl-c doesn't interrupt the debugee and return control to gdb. So if I "continue" with no active breakpoints I can never stop the process again, it has to be killed/interrupted from another shell. BTW, running "kill -s SIGINT <pid>" where <pid> is the debuggee's pid does get me back to gdb's prompt... but it is really annoying to have to do things this way

该脚本有效,但有一点需要注意。 ctrl-c不会中断debugee并将控制权返回给gdb。因此,如果我“继续”没有活动断点,我永远不能再次停止该过程,它必须从另一个shell中被杀死/中断。顺便说一下,运行“kill -s SIGINT ”,其中是调试对象的pid确实让我回到了gdb的提示......但是这样做是非常烦人的

At first I thought Python was grabbing the SIGINT signal, but this doesn't seem to be the case as I set up signal handlers forward the signal to the debugee and that doesn't fix the problem.

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

I've tried various configurations to the python script (calling os.spawn* instead of subprocess, etc.) It seems that any way I go about it, if python launched the child process, SIGINT (ctrl-c) signals DO NOT to get routed to gdb or the child process.

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

Current line of thinking

目前的思路

This might be related to needing a separate process group id for the debugee & gdb...any credence to this?

这可能与debugee&gdb需要一个单独的进程组ID有关...对此有任何信任吗?

Possible bug with SELinux?

SELinux可能存在错误?

Info:

gdb 6.8
Python 2.5.2 (problem present with Python 2.6.1 as well)

Python 2.5.2(Python 2.6.1中也存在问题)

SELinux Environment (bug delivering signals to processes?)

SELinux环境(向进程发送信号的错误?)

Alternatives I've considered:

我考虑的替代方案:

Setting up a .gdbinit file to do as much of what the script does, environment variables and current working directory are a problem with this approach.

设置.gdbinit文件以执行脚本执行的操作,环境变量和当前工作目录是此方法的问题。

Launching executable and attaching gdb manually (yuck)

启动可执行文件并手动附加gdb(yuck)

Question: How do you automate the launching/debugging of large scale projects?

问题:如何自动启动/调试大型项目?

Update: I've tried Nicholas Riley's examples below, on my Macintosh at home they all allow cntl-c to work to varrying degrees, on the production boxen (which I now to believe may be running SELinux) they don't...

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

3 个解决方案

#1

Instead of forwarding the signal to the debuggee from Python, you could try just ignoring it. The following worked for me:

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

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

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

With this I was able to ^C repeatedly inside GDB and interrupt the debuggee without a problem, however I did see some weird behavior.

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

Incidentally, I also had no problem when forwarding the signal to the target process.

顺便说一下,在将信号转发到目标进程时我也没有问题。

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])

So, maybe something else is going on in your case? It might help if you posted some code that breaks.

那么,在您的情况下可能会发生其他事情?如果你发布一些破解的代码,它可能会有所帮助。

3 个解决方案

#1

更多相关文章

随机推荐