デバッグ

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

ソフトウェアの場合、デバッグ戦術には、対話型デバッグ、制御フロー分析、ログ ファイル分析、アプリケーションまたはシステムレベルでの監視、メモリ ダンプ、およびプロファイリングが含まれます。多くのプログラミング言語とソフトウェア開発ツールでは、デバッガーと呼ばれるデバッグを支援するプログラムも提供されています。

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

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

同様に、デバッグという用語は、コンピュータの世界に入る前から航空学で使用されていました。ロスアラモスで第二次世界大戦の原子爆弾マンハッタン計画の責任者を務めたJ. ロバート オッペンハイマーは、カリフォルニア大学バークレー校のアーネスト ローレンス博士に 1944 年 10 月 27 日付で追加の技術スタッフの募集について手紙を送り、デバッグという用語を使用しました^{[2] 。}オックスフォード英語辞典のデバッグの項目では、1945 年の Journal of the Royal Aeronautical Society の記事で、飛行機のエンジン テストに関してデバッグという用語が使用されています。「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 は、低レベルソフトウェアおよびファームウェアに対して、一般的なソフトウェア デバッガのタスクの多くを実行できます。

デバッグ プロセスは通常、問題を再現する手順を特定することから始まります。これは、特に並列プロセスや一部のHeisenbugsなどの場合、簡単な作業ではありません。特定のユーザー環境や使用履歴によっても、問題を再現することが困難になる場合があります。

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

テストケースが十分に簡素化されたら、プログラマーはデバッガー ツールを使用してプログラムの状態 (変数の値とコール スタック) を調べ、問題の原因を突き止めることができます。または、トレースを使用することもできます。単純なケースでは、トレースはプログラムの実行中に特定の時点で変数の値を出力するいくつかの print ステートメントにすぎません。^{[引用が必要]}

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

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

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

組み込みシステムのデバッグでは、システム内のバグを特定するという一般的なタスクに加えて、システムの動作状態に関する情報も収集します。この情報は、システムの分析に使用して、パフォーマンスを向上させる方法を見つけたり、その他の重要な特性 (エネルギー消費、信頼性、リアルタイム応答など) を最適化したりするために使用できます。

アンチデバッグとは、「コンピュータコード内に、リバースエンジニアリングやターゲットプロセスのデバッグを妨害する1つ以上の技術を実装すること」です。^{[23]アンチデバッグは、有名な出版社が}コピー防止スキーマで積極的に使用していますが、マルウェアによっても検出と除去を困難にするために使用されています。^[24]アンチデバッグで使用される技術には次のものがあります。

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

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

• Agans, David J. (2002)。『デバッグ: 最も見つけにくいソフトウェアとハ​​ードウェアの問題も見つけるための 9 つの必須ルール』AMACOM。ISBN 0-8144-7168-4。
• Blunden, Bill (2003)。ソフトウェアエクソシズム:レガシーコードのデバッグと最適化のハンドブック。APress。ISBN 1-59059-234-4。
• フォード、アン R.、テオリー、トビー J. (2002)。C++ での実践的なデバッグ。プレンティス ホール。ISBN 0-13-065394-2。
• Grötker, Thorsten; Holtmann, Ulrich; Keding, Holger; Wloka, Markus (2012)。『開発者のためのデバッグガイド、第 2 版』。Createspace。ISBN 978-1-4701-8552-7。
• メッツガー、ロバート C. (2003)。『思考によるデバッグ：多分野にわたるアプローチ』。デジタル プレス。ISBN 1-55558-307-5。
• マイヤーズ、グレンフォード J (2004)。ソフトウェアテストの芸術。John Wiley & Sons Inc. ISBN 0-471-04328-1。
• Robbins, John (2000)。アプリケーションのデバッグ。Microsoft Press。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。
• Peggy Aldrich Kidwell、「Stalking the Elusive Computer Bug」、IEEE Annals of the History of Computing、1998 年。

Wikiquote には、デバッグに関する引用があります。

ウィキブックのコンピュータプログラミングの原則には、デバッグに関するページがあります。

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