2

ncursesクライアントで TUI ツールキットとして使用する小さなクライアント/サーバー アプリケーションを作成しています。クライアントはマルチスレッドで、(ソケット経由で) サーバーとの通信に使用されるスレッドと、UI を処理するスレッドがあります。バグを発見したので、クライアントの指示に従って、問題がどこにあるかを確認したいと思います1。

クライアントと同じターミナルを使用するため、クライアントを実行するだけでgdbは機能しませんgdb。したがって、出力がすべてめちゃくちゃになり、出力を読み取るのが非常に難しくなり、gdb干渉するようにも見えますcurses(たとえば、halfdelayステップ実行時のモード)プログラムgdbが少しの時間の後にドロップするたびに、クライアントにキープレスを送信することはできません.)

gdb「専用端末」で実行する方法はありますか? このアプリケーションをデバッグするには、別のアプローチを使用する必要がありますか? この特定のコンテキストで障害の数を減らす方法について何か提案はありますか?

1実際のバグは、UI が一定数のアクションの後 (完全に決定論halfdelay的な方法で) 更新されず、余分なキー押下を待機することです (これを回避するためにモードを正確に設定したため、これは必要ありません)。 . クライアントがその瞬間に何をしているのかを知りたいのです。

4

2 に答える 2

5

ttygdb コマンドを使用して、gdb とプログラムの出力を分離できます。Peterのgdbチュートリアルからの詳細な手順は次のとおりです。

最初の xterm に移動し、tty または who am i を使用してそのデバイス ファイルを見つけます。これは、GDB の I/O を備えた xterm になります。

   $ tty
   /dev/pts/1
   $ who am i
   p        pts/1        May 26 12:44 (:0.0)

2 番目の xterm に移動し、そのデバイス ファイルを見つけます。これは、プログラムの I/O を持つ xterm になります。

   $ tty
   /dev/pts/4

最初の xterm に戻り、デバッグ セッションを開始します。Print_A_Character() にブレークポイントを設定します。

   $ gdb debugging_ncurses
   (gdb) break Print_A_Character 
   Breakpoint 1 at 0x80486fd: file debugging_ncurses.c, line 26.
   (gdb)

GDB の tty コマンドは、プログラムの I/O を別の端末にリダイレクトするよう GDB に指示します。tty への引数は、プログラム I/O を実行したい端末のデバイス ファイルです。この場合、プログラムの I/O を 2 番目の xterm である pts/4 に移動させたいと考えています。手順に従っている場合は、手順 2 で取得したデバイス ファイルを使用します。

   (gdb) tty /dev/pts/4
   (gdb)

最後に、2 番目の xterm (プログラムの I/O を含む) に移動し、シェルに長時間スリープするように指示します。これは、そのウィンドウに入力したものはすべて、シェルではなくプログラムに確実に送られるようにするためです。時間の長さは任意ですが、デバッグ セッションが続くと思われる時間よりも長い時間を選択してください。これは、シェルに 100000 秒間「何もしない」ように指示します。

   $ tty
   /dev/pts/4
   $ sleep 100000

GDB を実行している最初の xterm に戻り、心ゆくまでデバッグします。完了したら、プログラムの出力ウィンドウに戻り、control-c を押してスリープから抜け出すことができます。

于 2013-04-30T16:44:00.140 に答える