デバッグ

エンジニアリングにおいて、デバッグとは、バグの根本原因、回避策、および可能な修正方法を見つけるプロセスです。

ソフトウェアのデバッグ手法には、対話型デバッグ、制御フロー解析、ログファイル解析、アプリケーションレベルまたはシステムレベルでの監視、メモリダンプ、プロファイリングなどが含まれます。多くのプログラミング言語やソフトウェア開発ツールには、デバッガと呼ばれるデバッグ支援プログラムも用意されています。

欠陥という意味での「バグ」という用語は、少なくとも1878年にトーマス・エジソンが自身の発明における「小さな欠陥や困難」を「バグ」と記した時まで遡る。

1940年代の有名な話に、グレース・ホッパー提督の話がある。^{[ 1 ]}彼女がハーバード大学でマークIIコンピュータに取り組んでいたとき、同僚がリレーに蛾が挟まって動作を妨げているのを発見し、ログブックに「バグが発見された最初の実際の事例」と書き込んだ。おそらく冗談で、バグ（生物学的バグと欠陥バグ）の2つの意味を混同しているが、この話は当時コンピュータ分野でこの用語が使われていたことを示している。

同様に、デバッグという用語は、コンピュータの世界に入る前から航空学で使用されていました。第二次世界大戦中のロスアラモスの原子爆弾マンハッタン計画の責任者であったJ・ロバート・オッペンハイマーは、 1944年10月27日付でカリフォルニア大学バークレー校のアーネスト・ローレンス博士に宛てた手紙の中で、追加の技術スタッフの採用に関してこの用語を使用しています^{[ 2 ]} 。オックスフォード英語辞典のdebugの項目では、 1945年の王立航空協会誌の記事で、飛行機のエンジンのテストに関してデバッグという用語が使用されています。「Airforce」（1945年6月号、50ページ）の記事では、航空機のカメラのデバッグについて言及しています。 

^{1951年のギル[ 3 ]}による画期的な論文は、プログラミングエラーに関する最も初期の詳細な議論ですが、バグやデバッグという用語は使用されていません。

ACMのデジタルライブラリでは、デバッグという用語は1952年のACM全国会議の3つの論文で初めて使用されています。^{[ 4 ] [ 5 ] [ 6 ]} 3つのうち2つは、この用語を引用符で囲んで使用しています。

1963年までに、デバッグはCTSSマニュアルの1ページ目に説明なしでさりげなく言及されるほど一般的な用語になっていた。^{[ 7 ]}

ソフトウェアや電子システムが一般的に複雑化するにつれて、さまざまな一般的なデバッグ手法も拡大し、異常を検出したり、影響を評価したり、ソフトウェアのパッチやシステム全体のアップデートをスケジュールしたりするための方法が増えてきました。「異常」や「不一致」といった中立的な用語を使用することで、「エラー」や「欠陥」または「バグ」といった用語の使用を避けることができます。これらの用語では、いわゆるエラー、欠陥、バグはすべて（どんな犠牲を払ってでも）修正しなければならないという含みがある可能性があるからです。代わりに、影響評価を実施して、異常（または不一致）を解消するための変更がシステムにとって費用対効果が高いかどうか、あるいは予定されている新しいリリースによって変更が不要になるかどうかを判断できます。すべての問題がシステムの安全性やミッションに重大な影響を与えるわけではありません。また、変更によってユーザーが長期的に見て、既知の問題を抱えたまま生活するよりも不便を感じるような状況（「治療が病気よりも悪い」状況）を避けることも重要です。異常の許容度に基づいて判断を下すことで、「欠陥ゼロ」を義務付ける文化、つまり問題の存在を否定して結果として欠陥ゼロに見せかけようとする風潮を回避できます。費用対効果の評価といった付随的な問題を考慮すると、より広範なデバッグ手法が展開され、異常の発生頻度（同じ「バグ」がどのくらいの頻度で発生するか）を特定し、システム全体への影響を評価するのに役立ちます。

デバッグの複雑さは、単純なエラーの修正から、データ収集、分析、更新スケジュールの設定といった時間のかかる面倒な作業まで多岐にわたります。プログラマーのデバッグスキルは、問題のデバッグ能力に大きく影響しますが、ソフトウェアデバッグの難易度はシステムの複雑さによって大きく異なり、使用するプログラミング言語やデバッガなどの利用可能なツールにもある程度依存します。デバッガは、プログラマーがプログラムの実行を監視したり、停止したり、再開したり、ブレークポイントを設定したり、メモリ内の値を変更したりできるようにするソフトウェアツールです。デバッガという用語は、デバッグを行う人を指す場合もあります。

一般的に、Javaのような高水準プログラミング言語は、例外処理や型チェックといった機能を備えているため、異常動作の真の原因を特定しやすく、デバッグが容易です。一方、C言語やアセンブリ言語のようなプログラミング言語では、バグによってメモリ破損などの問題が静かに発生することがあり、問題の発生源を特定するのが難しい場合がよくあります。そのような場合は、メモリデバッガツールが必要になることがあります。

特定の状況においては、言語固有の汎用ソフトウェアツールが非常に役立つ場合があります。これらは静的コード解析ツールという形で現れます。これらのツールは、コンパイラやインタプリタのように構文ではなく意味論（データフローなど）に重点を置き、ソースコード内の既知の問題（一般的なものから稀なものまで）を非常に具体的に探し出します。

様々な言語に対応した商用ツールと無料ツールが存在し、中には数百もの異なる問題を検出できると謳っているものもあります。これらのツールは、コードウォークスルーが現実的でない非常に大きなソースツリーをチェックする際に非常に役立ちます。検出される問題の典型的な例としては、変数に値が代入される前に発生する変数の逆参照が挙げられます。また、別の例として、言語が要求していない場合でも、強力な型チェックを実行するツールもあります。そのため、構文的に正しいコード内の可能性のあるエラーを見つけるのに優れています。しかし、これらのツールには誤検出が多いという評判があり、正しいコードが疑わしいとフラグ付けされることがあります。古いUnixのlintプログラムはその初期の例です。

電子ハードウェア（コンピュータハードウェアなど）や低レベルソフトウェア（BIOS、デバイスドライバなど） 、ファームウェアのデバッグには、オシロスコープ、ロジックアナライザ、インサーキットエミュレータ（ICE）などの計測器が、単独または組み合わせてよく使用されます。ICEは、低レベルソフトウェアやファームウェアに対して、一般的なソフトウェアデバッガの多くのタスクを実行できます。

デバッグプロセスは通常、問題の再現手順を特定することから始まります。これは、特に並列処理や一部のハイゼンバグなどにおいては、容易ではない作業となる場合があります。また、ユーザー固有の環境や使用履歴によって、問題の再現が困難になることもあります。

バグが再現されたら、デバッグを容易にするためにプログラムの入力を簡略化する必要がある場合があります。たとえば、コンパイラのバグによって、大きなソースファイルを解析する際にクラッシュすることがあります。しかし、テストケースを簡略化すれば、元のソースファイルから数行だけを抜き出すだけで同じクラッシュを再現できる場合があります。簡略化は、分割統治法を用いて手動で行うことができます。この方法では、プログラマーは元のテストケースの一部を削除し、問題がまだ発生するかどうかを確認します。GUIでデバッグする場合、プログラマーは元の問題の説明からユーザー操作の一部をスキップして、残りの操作でバグが発生するかどうかを確認できます。

テストケースが十分に単純化されたら、プログラマはデバッガツールを使用してプログラムの状態（変数の値とコールスタック）を調べ、問題の発生源を追跡できます。あるいは、トレースを使用することもできます。単純なケースでは、トレースはプログラムの実行中の特定の時点で変数の値を出力するいくつかのprint文にすぎません。^{[ 8 ]}

• 対話型デバッグでは、デバッガツールを使用してプログラムの実行を1ステップずつ処理し、一時停止して状態を検査または変更します。サブルーチンや関数呼び出しは通常、フルスピードで実行され、呼び出し元に戻ったときに再び一時停止するか、ステップ実行するか、またはこれらのオプションを組み合わせることができます。ブレークポイントを設定すると、問題がないと思われるコードはフルスピードで実行され、問題のある箇所で停止します。プログラムループの終了直後にブレークポイントを設定すると、繰り返し実行されるコードを評価するのに便利です。ウォッチポイントは一般的に利用可能で、特定の変数が変更されるまで実行を継続できます。また、キャッチポイントを使用すると、例外や共有ライブラリのロードなど、特定の種類のプログラムイベントが発生したときにデバッガを停止できます。
• プリントデバッグまたはトレースとは、プロセスの実行フローとデータの進行状況を示すトレースステートメントまたはプリントステートメントを（リアルタイムまたは記録された状態で）監視する行為です。トレースは、専用ツール（GDBのトレースなど）を使用するか、ソースコードにトレースステートメントを挿入することによって行うことができます。後者は、デバッグまたはトレースと呼ばれることもあります。printf デバッグは、C 言語のprintfの使用に起因するものです。、初心者向けのBASICTRONコマンドによって有効になっていました。TRON は「Trace On」の略です。TRON を有効にすると、プログラムの実行中に各 BASIC コマンド行の行番号が出力されました。
• アクティビティトレースは、上記のトレースと同様ですが、プログラムの実行を命令や関数ごとに追跡するのではなく、プロセッサ/CPUが特定のコードセグメントの実行に費やした時間全体に基づいてプログラムのアクティビティを追跡します。これは通常、定義されたメモリ アドレス (マシン コード プログラム) または特定のプログラム モジュール (高級言語またはコンパイル済みプログラム) 内の命令の処理に費やされたプログラム実行時間の割合として表されます。デバッグ対象のプログラムがトレースされた領域で実行時間の過大な割合を費やしていることが示された場合、これはプログラム ロジックの欠陥によるプロセッサ 時間の誤った割り当て、または少なくとも最適化によって改善できる非効率的なプロセッサ 時間の割り当てを示している可能性があります。
• リモートデバッグとは、デバッガとは異なるシステム上で実行されているプログラムをデバッグするプロセスです。リモートデバッグを開始するには、デバッガはローカルエリアネットワーク。その後、デバッガはリモートシステム上でのプログラムの実行を制御し、その状態に関する情報を取得できます。
• 事後デバッグとは、プログラムがクラッシュした後にデバッグを行うことです。関連する手法には、ログファイルの調査、クラッシュ時のコールスタックの出力^{[ 9 ]} 、クラッシュしたプロセスのメモリダンプ（またはコアダンプ）の分析など、さまざまなトレース手法が含まれます。プロセスのダンプは、システムによって自動的に取得される場合（たとえば、処理されない例外によってプロセスが終了した場合）、プログラマが挿入した命令によって取得される場合、または対話型ユーザーによって手動で取得される場合があります。
• 「オオカミの柵」アルゴリズム：エドワード・ガウスは、1982年にCommunications of the ACMの記事で、このシンプルながら非常に有用で今では有名なアルゴリズムを次のように説明しました。「アラスカにはオオカミが1匹います。どうやって見つけますか？まず、州の真ん中に柵を作り、オオカミが遠吠えするのを待ち、柵のどちら側にいるかを判断します。オオカミが見える地点に到達するまで、その側だけでこのプロセスを繰り返します。」^{[ 10 ]}これは、例えばGitバージョン管理システムでgit bisectコマンドとして実装されており、上記のアルゴリズムを使用して、どのコミットが特定のバグを導入したかを判断します。
• 記録再生デバッグとは、プログラムの実行記録を作成する手法です（例えば、Mozillaの無料デバッグツールrrを使用し、可逆的なデバッグ/実行を可能にする）。この記録は再生して対話的にデバッグできます。リモートデバッグや、断続的、非決定論的、その他再現が困難な不具合のデバッグに役立ちます。
• タイムトラベルデバッグとは、ソースコードを遡って（例えば、 Undo LiveRecorderを使用して）実行することで、コンピュータプログラムの実行中に何が起こっているのかを理解し、ユーザーがプログラムと対話できるようにし、必要に応じて履歴を変更し、プログラムがどのように反応するかを観察するプロセスです。
• デルタデバッグ-テストケースの簡略化を自動化する手法。 ^{[ 11 ] : p.123 [ 12 ]} 
• Saff Squeeze –失敗したテストの一部を段階的にインライン化することによって、テスト内の失敗を分離するテクニック。^{[ 13 ] [ 14 ]} 
• 因果関係の追跡：計算における原因と結果の連鎖を追跡する手法があります。^{[ 15 ]}これらの手法は、ヌルポインタの逆参照などの特定のバグに合わせて調整できます。^{[ 16 ]}
• ショットガンデバッグ：主に方向性のないソースコードの変更によってバグを修正しようとするプロセスであり、場合によってはさらなる問題を引き起こす。^{[ 17 ]}
• 障害箇所特定とは、障害が含まれている可能性のあるプログラム要素（ステートメント、メソッド、またはコンポーネント）を自動的に特定する技術です。最新のアプローチでは、機械学習を使用して特定精度を向上させています。 ^{[ 18 ]}

汎用コンピュータソフトウェア設計環境とは対照的に、組み込み環境の主な特徴は、開発者が利用できるプラットフォーム（CPUアーキテクチャ、ベンダー、オペレーティングシステム、およびその派生版）の種類の多さです。組み込みシステムは、定義上、汎用設計ではありません。通常、単一のタスク（または少数のタスク）向けに開発され、プラットフォームはそのアプリケーションを最適化するために特別に選択されます。この事実は、組み込みシステム開発者にとって作業を困難にするだけでなく、プラットフォームごとに異なるデバッグツールが必要となるため、これらのシステムのデバッグとテストも難しくします。

前述の異種混在の課題にもかかわらず、いくつかのデバッガは商用として、また研究プロトタイプとして開発されています。商用ソリューションの例としては、Green Hills Software ^{[ 23 ]} 、 Lauterbach GmbH ^{[ 24 ]}、MicrochipのMPLAB-ICD（インサーキットデバッガ用）などがあります。研究プロトタイプツールの例としては、Aveksha ^{[ 25 ]とFlocklab [ 26 ]}があります。これらはすべて、低コストの組み込みプロセッサで利用可能な機能であるオンチップデバッグモジュール（OCDM）を活用しており、その信号は標準のJTAGインターフェースを介して公開されます。これらのデバッガは、アプリケーションにどれだけの変更が必要か、また処理できるイベントのレートに基づいてベンチマークされています。

組み込みシステムのデバッグは、システム内のバグを特定するという一般的な作業に加えて、システムの動作状態に関する情報を収集することも目的としています。収集した情報は、システムの分析に利用され、パフォーマンスの向上や、その他の重要な特性（エネルギー消費量、信頼性、リアルタイム応答など）の最適化に役立てられます。

アンチデバッグとは、「コンピュータコード内に、対象プロセスのリバースエンジニアリングやデバッグの試みを妨害する1つ以上の技術を実装すること」である。 ^{[ 27 ]}これは、著名な出版社がコピープロテクションスキームで積極的に使用しているが、マルウェアも検出や駆除を困難にするために使用している。^{[ 28 ]}アンチデバッグで使用される技術には、次のものがある。

• APIベース：システム情報を使用してデバッガの存在を確認する
• 例外ベース: 例外が妨害されていないか確認します
• プロセスブロックとスレッドブロック：プロセスブロックとスレッドブロックが操作されたかどうかを確認する
• 変更されたコード：ソフトウェアブレークポイントを処理するデバッガによって行われたコードの変更をチェックします。
• ハードウェアおよびレジスタベース：ハードウェアブレークポイントとCPUレジスタをチェックする
• タイミングとレイテンシ：命令の実行にかかる時間を確認します
• デバッガーの検出とペナルティ^{[ 28 ]}

初期のアンチデバッグの例としては、 Microsoft Wordの初期バージョンがあり、デバッガーが検出されると、「悪の木は苦い実を結びます。プログラムディスクを破棄します。」というメッセージが表示され、その後、フロッピーディスクドライブから警告音が鳴り、ユーザーが再び試みないようにする意図があった。^{[ 29 ] [ 30 ]}

• アガンズ、デイビッド・J. (2002).デバッグ：最も見つけにくいソフトウェアおよびハードウェアの問題さえも見つけるための9つの必須ルール. AMACOM. ISBN 0-8144-7168-4。
• ブランデン、ビル（2003）。ソフトウェアエクソシズム：レガシーコードのデバッグと最適化のためのハンドブック。APress。ISBN 1-59059-234-4。
• フォード、アン・R.、テオリー、トビー・J. (2002). C++ の実践的デバッグ. プレンティス・ホール. ISBN 0-13-065394-2。
• グロットカー、トルステン。ホルトマン、ウルリッヒ。ケディング、ホルガー。ヴロカ、マルクス (2012)。デバッグのための開発者ガイド、第 2 版。スペースを作成します。ISBN 978-1-4701-8552-7。
• メッツガー、ロバート・C. (2003).思考によるデバッグ：学際的アプローチ. デジタルプレス. ISBN 1-55558-307-5。
• マイヤーズ、グレンフォード J (2004).ソフトウェアテストの技術. ジョン・ワイリー・アンド・サンズ社. ISBN 0-471-04328-1。
• ロビンス、ジョン（2000）。アプリケーションのデバッグ。マイクロソフトプレス。ISBN 0-7356-0886-5。
• テレス、マシュー A.、シェイ、ユアン (2001)。デバッグの科学。コリオリス グループ。ISBN 1-57610-917-8。
• ヴォストコフ、ドミトリー（2008）。メモリダンプ分析アンソロジー第1巻。OpenTask。ISBN 978-0-9558328-0-2。
• ツェラー、アンドレアス（2009）。『なぜプログラムは失敗するのか、第2版：体系的なデバッグの手引き』。モーガン・カウフマン。ISBN 978-0-1237-4515-6。
• ペギー・アルドリッチ・キッドウェル、「捉えどころのないコンピュータバグを追跡する」、IEEE Annals of the History of Computing、1998年。

• クラッシュダンプ分析パターン–クラッシュダンプの分析とバグ発見に関する詳細な記事 
• デバッグの基本–デバッグスキルを向上させる方法 
• 組み込みシステム向けプラグインベースデバッグ（ 2019年12月10日、 Wayback Machineにアーカイブ済み）
• 組み込みシステムのテストとデバッグ – デジタル入力生成について–組み込みシステムのテストとデバッグに関する調査結果、Byte Paradigm（2012年1月12日のオリジナル記事をアーカイブ）