dbx を使用してプロセスを監視しますが、監視によってプロセスが妨げられるべきではありません。しかし、時によって、プロセスの状態を大幅に変わる可能性があります。さらに、簡単な監視によって、実行が妨げられ、原因不明のバグ症状が現れることもときどきあります。
アプリケーションは、dbx のもとで実行される場合、本来と動作が異なることがあります。dbx は被デバッグプログラムに対する影響を最小限に抑えようとはしますが、 次の点に注意する必要があります。
-C オプション付きで起動しないでください。また、RTC は無効にしてください。RTC のライブラリの librtc.so をプログラムに読み込むと、プログラムの動作が変わる可能性があります。
dbx 初期化スクリプトで環境変数が設定されていることを忘れないでください。スタックベースは、dbx のもとで実行する場合、異なるアドレスから始まります。これは、各自の環境と argv[] の内容によっても異なり、局所変数の割り当てが若干異なります。これらが初期化されていないと、異なる乱数を受け取ります。この問題は、実行時検査によって検出できます。
プログラムは、使用前に malloc()() されたメモリーを初期化しません。これは、前述の状態と似ています。この問題は、実行時検査によって検出できます。
dbx は LWP 作成イベントと dlopen イベントを捕獲しなければならず、これによって、タイミングに左右されやすいマルチスレッドアプリケーションが影響を受ける可能性があります。
dbx は、シグナルに対するコンテキスト切り替えを実行するため、タイミングに影響を受けるシグナルを多用する場合、動作が異なってしまうおそれがあります。
プログラムは、mmap() が、マップされたセグメントについて常に同じベースアドレスを返すことを期待します。dbx のもとで実行すると、アドレス空間が混乱して、mmap() は dbx を使用しないでプログラムを実行したときと同じアドレスを返せなくなります。プログラムでこのことが問題になるかどうかを判断するには、mmap() の使用場所をすべて調べて、返される値がハードコードされたアドレスではなく、プログラムによって実際に使用されることを確認してください。
プログラムがマルチスレッド化されている場合、データの競合が存在するか、またはスレッドスケジュールに依存する可能性があります。dbx のもとで実行すると、スレッドスケジュールが混乱して、プログラムが通常の順序とは異なる順序でスレッドを実行するおそれがあります。このような状態を検出するには、lock_lint を使用してください。
あるいは、adb または truss を使用して実行した場合に同じ問題が起こるか確認してください。
dbx によって強いられる混乱を最小限に抑えるには、アプリケーションが自然な環境で実行されているときに dbx を接続するようにしてください。