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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了python – 如何自动启动/调试大型项目？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2038字，纯文字阅读大概需要3分钟。

内容图文

场景：

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

流程启动脚本：

>确保设置环境变量.
>确保将本地构建目录添加到环境的LD_LIBRARY_PATH变量中.
>将当前工作目录更改为可执行文件期望的位置(不是我的设计)
>使用配置文件启动可执行文件唯一的命令行选项
>将可执行文件的输出传递给第二个日志记录进程
>记住可执行文件的PID,然后启动&将gdb附加到正在运行的可执行文件

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

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

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

目前的思路

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

信息：

> gdb 6.8
> Python 2.5.2(Python 2.6.1也存在问题)
> SELinux环境(向进程发送信号的错误？)

我考虑的替代方案：

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

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

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

解决方法:

您可以尝试忽略它,而不是将信号从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])

那么,你的情况可能会发生其他事情吗？如果你发布一些破解的代码,它可能会有所帮助.

内容总结

以上是互联网集市为您收集整理的python – 如何自动启动/调试大型项目？全部内容，希望文章能够帮你解决python – 如何自动启动/调试大型项目？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端