シナリオ:
手で起動するのが面倒な複雑なソフトウェアがあります。私が行ったことは、実行可能ファイルを起動し、デバッグ用にgdbをアタッチするための Python スクリプトを作成することです。
プロセス起動スクリプト:
- 環境変数が設定されていることを確認します。
- ローカルのビルド ディレクトリが環境
LD_LIBRARY_PATH
変数に追加されるようにします。 - 現在の作業ディレクトリを実行可能ファイルが期待する場所に変更します(私の設計ではありません)
- 唯一のコマンドラインオプションである構成ファイルを使用して実行可能ファイルを起動します
- 実行可能ファイルからの出力を 2 番目のロギング プロセスにパイプします
- 実行可能ファイルの PID を記憶し、実行中の実行可能ファイルに gdb を起動してアタッチします。
スクリプトは機能しますが、1 つの注意点があります。ctrl-c はデバッグ対象を中断せず、制御を gdb に戻します。したがって、アクティブなブレークポイントなしで「続行」すると、プロセスを再び停止することはできず、別のシェルから強制終了/中断する必要があります。ところで、「kill -s SIGINT <pid>」を実行すると、<pid> はデバッグ対象の pid に戻りますが、gdb のプロンプトに戻ります...しかし、このようにしなければならないのは本当に面倒です
最初は、Python が SIGINT シグナルを取得していると思っていましたが、シグナル ハンドラーをセットアップしてシグナルをデバッグ対象に転送しても問題が解決しないため、そうではないようです。
私はpythonスクリプトにさまざまな構成を試しました(サブプロセスの代わりにos.spawn *を呼び出すなど)。pythonが子プロセスを起動した場合、SIGINT(ctrl-c)シグナルはしないようですgdb または子プロセスにルーティングされます。
現在の考え方
- これは、debugee と gdb に別のプロセス グループ ID が必要なことに関連している可能性があります...これに対する信憑性はありますか?
- SELinux のバグの可能性はありますか?
情報:
- gdb 6.8
- Python 2.5.2 (Python 2.6.1 にも存在する問題)
- SELinux 環境 (プロセスにシグナルを配信するバグ?)
私が検討した代替案:
- .gdbinit ファイルを設定して、スクリプトが行うことと同じように行うこと、環境変数、および現在の作業ディレクトリがこのアプローチの問題です。
- 実行可能ファイルを起動し、gdb を手動でアタッチする (yuck)
質問: 大規模プロジェクトの起動/デバッグをどのように自動化しますか?
更新: 以下の Nicholas Riley の例を試してみました。自宅の Macintosh では、すべて cntl-c がさまざまな程度で機能しますが、製品の boxen (SELinux を実行していると思われる) では動作しません...