dbx では、イベント機構によって、豊富な種類のブレークポイントが用意されていますが、内部でも多くのイベントが使用されています。これらの内部イベントのいくつかで停止することによって、dbx の内部の動作を簡単に中断することができます。さらに、これらの場合の処理状態を変更すると、中断できる機会が増えます。付録 A プログラム状態の変更と「安全な呼び出し」を参照してください。
場合によっては、dbx は自身を保護して中断を妨げることがありますが、すべての場合ではありません。一部のイベントは下位レベルのイベントという観点で実装されています。たとえば、すべてのステップ実行は fault FLTTRACE イベントに基づきます。そのため、コマンド stop fault FLTTRACE を発行すると、ステップ実行が停止します。
デバッグに続く段階では、dbx はユーザーイベントを処理できません。これは、ユーザーイベントにより精密な内部統合が妨げられるからです。このような段階には次のものが含まれます。
プログラムの起動時に rtld が実行された場合 (「動的リンカー」を参照)
プロセスの開始と終了時
fork() 関数と exec() 関数のあと (「fork 機能後のプロセス追跡」と 「exec 機能後のプロセス追跡」を参照)
dbx がユーザープロセスのヘッドを初期化する必要がある場合の呼び出し時 (proc_heap_init())
dbx がスタックのマップされたページを確実に利用できるようにする必要がある場合の呼び出し時 (ensure_stack_memory())
多くの場合、stop コマンドの代わりに when コマンドを使用して、情報を表示することができます。このコマンドを使用しない場合は、対話によって情報を取得する必要があります。
dbx は次のようにして自身を保護します。
sync、syncrtld、および prog_new イベントに stop コマンドを許可しない
rtld ハンドシェーク時および前述の段階で stop コマンドを無視する
次に例を示します。...stopped in munmap at 0xff3d503c 0xff3d503c: munmap+0x0004: ta %icc,0x00000008 dbx76: warning: 'stop' ignored -- while doing rtld handshake
$firedhandlers 変数での記録を含む停止効果のみが無視されます。カウントやフィルタはアクティブなままになります。このような場合で停止させるには、event_safety 環境変数を off に設定します。