ソフトウェア技術者のためのバグ百科事典（21）【総まとめ】バグの特定手順を解説：山浦恒央の“くみこみ”な話（142）（2/3 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

3.2 再現性を見つける

　バグの再現性、規則性が明らかになると、ほぼ、バグの原因を特定できたことになります。例えば、「10周期に1回で異常事象が発生する」「再テストでも同じ事象が再現する」などです。さまざまな入力値から、規則性を探します。例えば、実装抜けのバグ（第126回掲載）やビルド構成（第134回掲載）のバグについては、場合にもよりますが、入力が同じならば、同じ結果を返す可能性が高いでしょう（図2）。

図2　絶対値を求めるプログラム（左：バグありの絶対値取得関数、右：正しい絶対値取得関数）（クリックで拡大）

　図2は、絶対値を求めるプログラムの例題です。例えば、左のようなa < 0の場合は、何もしない条件を記述し忘れていた場合を考えます。左の例では、呼び出し側で、myabs(5)として呼び出すと「-5」となり、正しい絶対値となりません。ですが、5ともう一度入れれば、バグは再現します。

　苦労するのは、再現性が分かりにくいバグです。例えば、処理時間のバグ（第133回掲載）は、負荷が高いタイミングが作用するため、低負荷時にはバグが再現しない可能性があります。他にも複数のタスクやスレッドが非同期で動作する場合は、動作次第では不可解な事象が発生することも少なくありません。

　再現性があっても、再現性を見つけることは簡単ではありません。例えば、うるう年のバグ（第122回、第123回掲載）は、4年に1回という長い時間が関係します。この場合、バグの特定に時間がかかるでしょう。

3.3 バグの原因を絞り込む

　バグの原因を特定するために、関係する箇所を絞り込みます。例えば、「バグの原因はハードウェアかソフトウェアか」「バグの原因は、OSか、当該アプリケーションプログラムか」「バグの原因はAモジュールが原因か」などを考察します。

　通信系プログラムのバグ（第140回掲載）の原因を調べるならば、機器の間にWireSharkなどのパケットキャプチャーツールを使います（図3）。

図3　UDPの送受信の例

　図3は、UDPの送受信の例題を示しました。「機器Aからデータを送信できるが、機器Bに届かない」という事象の場合、「送信先の指定が関係しているか」「LANケーブルが断線しているか」などの絞り込みが可能です。

3.4 不良の箇所を見つける

　バグがある範囲を絞り込んだら、ソースコードを読み、関連する変数を表示し、不良の箇所を見つけます（図4）。

図4　無限ループの例

　図4は、無限ループの例です。仕様やプログラムを追うと、不良の箇所が見つかります。単純なコーディングのバグ（第135回、第138回掲載）や境界値のバグ（第130回掲載）の場合、「何でこんなミスをしてしまったのだろう」と落ち込むことも少なくありません。

3.5 対策を立案する

　バグの場所が分かると、バグの修正および確認方法を立案します。ただし、フェーズによっては、バグを修正したくてもできないことがありますね。例えば、仕様変更（第136回掲載）に関わるバグ、要求仕様のバグ（第128回掲載）や、残りの予算が十分でない場合、運用方法でカバーする必要があります。