2

C++ プログラムの gdb と dbx の両方のフロントエンドとして ddd を使用しています。

多くの場合、明白な原因がなくても、next「gdb の準備が整うのを待っています」または「dbx の準備が整うのを待っています」というメッセージが表示されてハングします。

彼らが何をしていて、永遠に時間がかかり、明らかな結果をもたらさないのか、誰か知っていますか? そして、私はそれが起こるのを止めることができますか?

同じプロセス (および同じ関数) で 1 分前にステップ実行/次へ進むのに十分な量のものが既にロードされていることを心に留めておいてください。 . また、ddd と dbx の両方が同じ動作パターン (多くの異なる実行可能ファイルおよび異なるプラットフォームで) を持っているという事実は、どちらのデバッガーのバグではなく、データ内の何かであると私に思わせます。

4

1 に答える 1

4

GDB (および DBX にも同じことが当てはまります) は、MI プロトコルを使用して DDD と通信します。MI プロトコルは、コマンドライン インターフェイスの標準化された明確な同等物です。

備考:私のシステム (Fedora 15) のデフォルトでは、CLI を使用して直接通信しているようですが、あなたが説明した問題にしか気づきませんでした--interpret=mi。

たとえば、スレッド リストを取得するためのそれぞれの出力は次のとおりです。

(gdb) info threads 
  Id   Target Id         Frame   
2    Thread 0x7ffff7fd2700 (LWP 9191) "philosophers" 0x00000037dcc0b4c5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0  
1    Thread 0x7ffff7fd3720 (LWP 9182) "philosophers" 0x00000037dc8df461 in clone ()   from /lib64/libc.so.6

(gdb) -thread-info 
^done,threads=[
   {id="2",target-id="Thread 0x7ffff7fd2700 (LWP 9525)",name="philosophers",
    frame={level="0",addr="0x0000000000400b31",
           func="chopsticks_put",
           args=[{name="i",value="0"}],
           file="chopsticks.c",fullname="philosphers/chopsticks.c",line="70"},
    state="stopped",core="2"},
   {id="1",target-id="Thread 0x7ffff7fd3720 (LWP 9522)",name="philosophers",
    frame={...},
    state="stopped",core="1"
   }],current-thread-id="3"

したがって、DDD で表示されるものは、CLI で使用できるものと非常に似ていますが、「プレゼンテーション レイヤー」だけが異なります。

私の経験から、ほとんどの GDB コマンドは、少なくともデバッグ対象の実行に依存しない場合 ( anextよりも a のようにsleep(5)) は非常に高速です。したがって、問題には2つの可能性があります。

  • 通信のバグ: たとえば、^doneタグが DDD によって失われたり、GDB によって忘れられたりするため、DDD は要求の終了を無駄に待ちます
  • DDD は、構造体の定義、関数の場所、メモリの内容など (たとえば、監視したい要素のため) などの大量のデータを GDB に要求するため、GDB によって情報が計算されるまでに時間がかかります。 DDDに移籍。

DDD の一番下にGDB console. そこにいくつかの GDB コマンドを入力してみてください。GDB が正しく応答する場合 (私の場合)、DDD が GDB と同期されなくなったことを意味します。(2009/02/11、DDD は古くなり、MI は Eclise で広く使用されているため、誰が責任を負うべきかはわかっていると思います...!)

于 2012-02-01T14:32:11.697 に答える