断続的なバグは、50フィートの不可視の電車から外宇宙の種類のバグのいとこです。この悪夢は非常にまれであり、観察するのは難しいですが、しばしばそれを無視することはできません。あなたがそれを見つけることができないので、デバッグすることはできません。
断続的なバグは、8時間後には疑問を持ち始めますが、他のすべてのロジックと同じ法則に従わなければなりません。それが難しいのは、それが未知の条件下でのみ起こるということです。バグが発生する状況を記録して、バラツキが本当に何であるかを推測できるようにしてください。条件はデータ値に関連している可能性があります。例えば、ワイオミング*を値として入力する場合にのみ発生します。それが変動性の原因でない場合、次の疑惑は並行性が不適切に同期される必要があります。
バグを制御された方法で再現しようとしてみてください。それを再現できない場合は、ロギングシステムを構築することでトラップを設定します。必要な場合は特別なログシステムを作成し、実際に発生したときに必要と思われるものをログに記録できます。バグがあなたの気まぐれではなく、プロダクションでのみ起こるならば、これは長いプロセスかもしれません。ログから得られるヒントは解決策を提供しないかもしれませんが、ログを改善するのに十分な情報を提供するかもしれません。改良されたロギングシステムは、生産に投入するまでに長い時間がかかることがあります。その後、バグが再発してより多くの情報を得るのを待たなければなりません。このサイクルはしばらくの間続くことができます。
私が今までに作成したばかげた断続的なバグは、クラスプロジェクトのための関数型プログラミング言語のマルチスレッド実装です。私は機能プログラムの正確な並行評価を非常に慎重に確保し、使用可能なすべてのCPU（この場合は8個）を有効に活用しました。ガベージコレクタの同期を忘れてしまった。システムは、何か目立つことが間違ってしまう前に、しばしば私が始めた仕事を終わらせる、長い時間を実行することができます。私の間違いが私に起こる前に、私がハードウェアに疑問を持ち始めたことを認めて恥ずかしい。
職場では最近、間欠的なバグがあり、数週間で見つけました。私たちは、Apache邃「Webサーバーの背後にあるJava邃「マルチスレッドアプリケーションサーバーを持っています。高速なページターンを維持するために、私たちはページめくりスレッドとは異なる4つの別々のスレッドの小さなセットですべてのI / Oを実行します。時々、これらは、明らかに、私たちの記録が私たちに何時間も伝えることができた限り、何か有用なことをやめさせることになります。私たちは4つのスレッドを持っていたので、4つすべてがスタックしていない限り、これはそれ自体巨大な問題ではありませんでした。これらのスレッドによって空にされたキューは、すべての使用可能なメモリをすばやく埋めて、サーバーをクラッシュさせます。このことを理解するのに1週間ほどかかりましたが、何が原因か、発生するか、スレッドが何をしているのかはまだ分かりませんでした。
これは、サードパーティのソフトウェアに関連するリスクを示しています。テキストからHTMLタグを削除したライセンスコードを使用していました。私たちはソースコードを持っていましたが、私たちはサーバーのログを立てるまで、慎重に研究していませんでした。私たちは最終的に、問題のあるライセンスコードに電子メールスレッドが詰まっていることに気付きました。
このプログラムは、長くて珍しい種類のテキストを除いて、うまくいった。これらの文章では、コードは二次的であったり、悪かったりします。これは、処理時間がテキストの長さの2乗に比例することを意味します。これらのテキストが一般的に発生していた場合は、すぐにバグを発見したはずです。彼らがまったく起こったことがなければ、私たちは決して問題を抱えませんでした。それが起こると、最終的に問題を理解し解決するまでに数週間かかりました。