コンピュータのバグまたはグリッチとは、コンピュータ プログラムが正常に機能しなくなる異常な現象です。その重大度は、良性 (軽度の表示障害) から重大 (アリアン 5 ロケットの 501 便の爆発) までの範囲に及びます。
バグは通常、ソフトウェア設計の問題によって発生します。エラーは特定できる場合もありますが (修正が簡単に実行される場合もあります)、プログラム自体の設計に起因する場合もあり、大幅な見直しが必要になります。まれに、ソフトウェアのプログラマーが使用する開発ツールのエラーがソフトウェアのバグの原因となる場合があります。最後に、プロセッサの初期バージョンに影響を与えた Pentium分割バグの場合と同様、ハードウェア自体にバグが存在する可能性があります。
言葉の由来
この用語は、ハードウェア エンジニアリングの専門用語から来ており、発生するハードウェア エラーを表す英語の単語bugに由来しています。この用語は、グレース ホッパーによるものであると誤って解釈されることもあります。逸話では、装置を動作させるリレーの 2 つの接点の間に挟まった昆虫(バグ) が、最初の電気機械式コンピューターの 1 つが誤動作した原因であることを彼女が発見したという逸話があります。
- 1946 年、ホッパーはハーバード大学の研究室の教員に加わり、そこでハーバード マーク II とハーバード マーク III の研究を続けました。彼女は Mark II のエラーの原因をリレーに巻き込まれた蛾のせいだと考え、 「バグ」という用語を作りました。昆虫は慎重に取り出され、日誌に記載されました。この最初の異常により、プログラム内のエラーを表すバグまたはバグという表現が普及しました。 [ 1 ]
上記の逸話は興味深いものですが、機械システムの故障を説明するためにバグという言葉が使用されたのは、少なくとも 1870 年代以前から、特にトーマス エジソンがメモの中でこの言葉を使用していたことが認識されています。したがって、この言葉の正確な起源が不明であるとしても、システム内の昆虫の存在による機能不全との関連は明らかであるように思われます。
英語のバグという用語はフランス語の「寄生虫」に由来します。フランスでは、これは電気技師が「回線に寄生している」という形で回線の問題を表す用語でした。英語に適応されてバグとなり、その後 DGLF の保護の下、「バグ」（栗？）の形でフランスに戻りました。 [参照。必要]バグは依然として非常に広く使用されています。
フランスでは、1983 年 12 月 30 日の官報に掲載された法令以来、「バグ」という用語がフランス語およびフランス言語総代表団 (DGLF) によって推奨されています。もっとフランス語では、語源を表現しません。このため、フランス語版を使用する人はほとんどいません。当時は女性の性別が推奨されていました。
しかし、 1990 年代の終わりに、「New Petit Robert」や「Le Petit Larousse Illustrated」などの辞書は、この用語が男性形で使用されていると報告しましたが、これは間違いなくフランス語事務局 (OQLF) が設置したケベック州の影響下にあったと考えられます。彼は長い間、男性性の使用を主張してきました。フランス語のこの用語は、有名な Y2K バグによって広まりました。このバグは、目に見える重大な機能障害を引き起こさなかったにもかかわらず、1990 年代に情報システムを変革するために多くの作業を必要としました。
DGLF は現在、この単語に男性の性別を使用することも推奨しています。
効果
悲観主義者は、すべてのコンピュータプログラムにはバグがあると言う。対照的に、高品質のプログラムにはエラーが比較的少なく、通常、システムのタスクの継続が妨げられることはありません。逆に、あまり良くないプログラム (バグがあると呼ばれることもあります) には、システムの動作を妨げる多くの異常が含まれています。
バグはさまざまな影響を及ぼします。一部はソフトウェアの動作に微妙な影響を及ぼし、長期間不明のままになる可能性があります。その他の場合はより深刻で、ソフトウェアが停止したり、システムがフリーズしたりする可能性があります。
オペレーティング システムの場合によっては、ソフトウェアのバグにより、リロードするまでシステムが不安定になることがあります。
その他のプログラミングエラーはセキュリティの脆弱性につながる可能性があります。バッファ オーバーフローは、ハッカーがターゲット マシン上で新しいプログラムを実行することを可能にする最も一般的なバグの 1 つです。
バグは経済的に大きな影響を与える可能性があります。 Steve McConnell は、1 億米ドル以上の費用がかかったいくつかのバグを説明しました。
- 最も驚くべき事例の 1 つは、 10 億ドル以上の費用がかかったヨーロッパのアリアン 5ロケットの事例です。離陸後しばらくして、航空機に搭載された誘導コンピュータのエラーにより破壊されました。ただし、この場合、「バグ」という用語はやや誤りです。実際、「エラー」は、慣性誘導ユニットの管理にアリアン 4で使用されたものと同じコンピューターとソフトウェアが使用されたことによって構成されており、コンピューターとソフトウェアは完全に機能しました。このロケットで。ただし、Ariane 5 コンピュータ システムの残りの部分は 64 ビット浮動小数点数で動作し、これらの要素は 16 ビット符号付き整数で動作しました。あるシステムから別のシステムに値を渡すときに、ハードウェア例外が発生しました (より正確には、64 ビットの数値が 16 ビットで表現するには大きすぎる値を持つ算術オーバーフローです。これにより、デフォルトのエラー処理動作: self が発生しました)。 -テスト)、その結果、軌道にずれが生じ、地上から修正することは不可能でした。
- 金星探査機マリナー 1 号も1962 年に同様の方法で失われました。Fortranプログラム内の忘れられたハイフンには 8,000 万ドル以上の費用がかかりました。アーサー・C・クラークによれば、それは「史上最も高価なハイフン」だったという。
- 2000 年の有名なバグは IT コンサルティング会社に富をもたらしましたが、1900 年から 1 月に発見された西暦 4 桁が正しく処理されないことを恐れて、企業はソフトウェアの大部分を変更せざるを得なくなるほど巨額の費用を費やすことになりました。 2000 年1 月
形式的アプローチ: 形式的手法
バグとは、システム仕様、つまりシステムが何を行うべきかの定義に準拠していないことです。仕様は非公式で曖昧なもの (「ソフトウェアは実行時エラーを引き起こさないワードプロセッサである」など) もあれば、形式的で正確なもの (「tri( t ) は tri ( t ) が次のようなtの順列である」) もあります。関係 < “) に対して順序付けされ、数式を取得するところまで含まれます。バグのあるプログラムとは、実装が仕様を満たしていないプログラムです。
プログラムにバグがあるかどうかを判断するために従うだけで済むような、普遍的で完璧な自動メソッドはあるのだろうかと疑問に思う人もいるかもしれません。答えはノーです。確かに、そのような方法があれば、コンピュータ、つまり解析ソフトによって自動化することが可能でしょう。このアナライザーは、分析対象の任意のプログラム上で動作する必要があり、たとえば、「プログラムの最終状態は実行時にエラー状態になる可能性があるのか、それとも必ず正しい状態 (または非終了) なのか」という質問に答える必要があります。 。しかし、ライスの定理によれば、この質問は無限状態システムでは答えることができません。より一般的には、プログラムの最終状態に関する仕様の質問は決定不可能です。つまり、答えが常に true または常に false である質問を除いて、ソフトウェアまたは自動メソッドはそれに答えることができません。
コンピュータは有限状態システムである、つまり各コンピュータには有限量のメモリがあるということに異論を唱える人もいるかもしれません。ただし、非常に小規模なシステムを除いて、分析目的では、コンピューターを無制限のメモリを持つシステムとみなすことが適切です。実際、状態の有限性を使用する解析手法はすべて、多かれ少なかれ間接的または最適化された方法で、システムの状態を列挙しようとします。 nビット メモリ システムには 2 n 個の状態があります。現在のパーソナル コンピュータでは、 n は2 38程度です。したがって、システムの状態を列挙しようとする試みは失敗する運命にあることがわかります。
したがって、普遍的な自動バグ検索の不可能性は根本的な問題であり、現在の技術の限界ではありません。
作り方は？どうすればそれを取り除くことができますか？
バグはプログラミング タスクの性質の結果として発生します。いくつかは、ソース コードを作成するプログラマーによる単純な不注意なエラーによって発生します。その他のバグは、ソフトウェアの異なる部分間の予期せぬ干渉、またはソフトウェアの外部のシステムの予期せぬ動作 (架空の値を返すセンサーの故障) の結果として発生します。最終的には、プログラマーが使用する言語とライブラリを定義する標準の正確な条件を考慮していないことから生じるものもあります (例を参照)。このような状況は、ソフトウェアが複雑すぎてプログラマーがプログラムの複数の部分間の相互作用の可能性をすべて考えることができない場合に発生することがあります。
ソフトウェア開発業界は、バグにつながるプログラマのエラーを防ぐ方法を見つけるために多大な努力を払っています。これには以下が含まれます。
- プログラミング規則。書き方の統一性（他の開発者が混乱する可能性を軽減）と詳細なドキュメントの作成を義務付けます。通常、プログラムの作成は、文書化された連続した段階の形式化されたプロセスに従う必要があります。
- プログラミング技術。バグにより、実行中のプログラムの内部データに不整合が生じることがあります。実行中に内部データの一貫性をチェックするプログラムを作成できます。問題が見つかった場合、ソフトウェアはただちにシャットダウンしてバグを見つけて修正することも、単にユーザーに通知して不整合の修正を試みて操作を続行することもできます。さらに、 プログラミング言語またはシステムの繊細な処理機能の使用を禁止するか、少なくとも厳しく規制することができます。
- 開発方法論。バグのリスクを最小限に抑えるためにプログラマのアクティビティを管理する方法がいくつかあります。これらのテクニックの多くは、ソフトウェア エンジニアリングの専門分野に分類されます。
- プログラミング言語のサポート。言語には、例外処理など、プログラマがバグに対処するのに役立つ機能が含まれることがあります。さらに、最近の言語のいくつかは、バグにつながる可能性のある高度な機能を意図的に除外しています。たとえば、Java 言語と Perl 言語はポインターへの低レベルのアクセスを提供しないため、プログラムが不用意にメモリ領域にアクセスすることを防ぎます。
- テスト。ソフトウェアは、困難な「極端な」構成を含むさまざまな構成でテストされます。また、すべての機能、ソフトウェアのすべてのコード部分、またはコード内のすべてのパスをカバーするように努めます (この最後の基準は通常、達成することが不可能です)。ただし、テストでは限られた数のシステム構成、ユーザーまたは外部からの入力などのみが考慮されるため、すべてのケースでソフトウェアが適切に動作するという保証はありません。
- 形式的な方法。ここでの目的は、ソフトウェアが正しく機能することを数学的な意味で証明することです。この方法は多かれ少なかれ自動化を提供できます。証明アシスタントは、ユーザーが数学的証明を作成して検証するのを支援します。抽象解釈によるモデルのチェックと静的分析は自動的に行われます。中間のグラデーションがあります。たとえば、パリの地下鉄14 番線(Meteor) で使用されるメソッド B を例に挙げてみましょう。
バグの発見と修正、またはデバッグは、ソフトウェア プログラミングの主要な部分です。コンピューターの先駆者モーリス ウィルクスは、1940 年代の自分の業績を、残りの人生のほとんどを自分のプログラムのエラーを修正することに費やすだろうと述べました。コンピュータ プログラムがますます複雑になるにつれて、バグが頻繁に発生し、修正するのが難しくなります。プログラマーは、新しいコードを書くよりも、バグの発見と修正に多くの時間と労力を費やすことがあります。
通常、デバッグで最も難しい部分は、エラーの原因となっているコードの部分を見つけることです。一度特定されれば、多くの場合、修正は簡単です。デバッガと呼ばれるプログラムは、プログラマがバグを見つけられるようにするために存在します。ただし、デバッガーの助けを借りたとしても、バグを見つけるのは非常に難しい作業であることがよくあります。
通常、バグを見つける最初のステップは、それを簡単に再現する方法を見つけることです。バグが再現されると、プログラマはデバッガまたはその他のツールを使用して、通常のコンテキストでプログラムの実行を観察し、問題を発見できる可能性があります。一方で、バグを再現するのは必ずしも簡単ではありません。一部は、プログラマが再現するのが難しいソフトウェアへの入力によって引き起こされます。プログラムをデバッガーで実行すると、他のプログラムが消える場合があります。これらはハイゼンバグと呼ばれます（冗談めかしてハイゼンベルクの不確定性原理を指します）。最後に、並列プログラム (複数のプロセッサーなどで同時に実行される複数のモジュールで構成される) のバグは、マシン上の計算の正確なスケジューリングに依存している場合、再現が困難であることがよくあります。
例
バグはないがエラーを引き起こす可能性があるコードの例。他のプログラムまたはマシンのエラーを検出する動作用にコードを修正しました。
- 次の疑似コードは、メモリアドレスを入力として受け取り、そこに格納されている値をインクリメントする関数を表します。
関数 IncPointer( ポインタ ) *ポインタ++ 終了関数
- 問題は、コンピュータ システムではメモリの一部のみが書き込み可能であることが一般的であり、保護されたメモリ領域または存在しないメモリ領域で書き込みを行おうとすると、バグやプログラムの中断、最悪の場合はシステムのシャットダウンが発生することです。
- 複雑なシステムでは、考えられるすべてのケースを予測するのは困難で退屈な場合が多いため、完全な許容誤差が存在しません。これは、プログラムを可能な限り堅牢にするために、できるだけ多くのケースを計画することを妨げるものではありません。
関数 IncPointer( ポインタ ) if IsValid( ポインタ ) *ポインタ++ 戻る OK さもないと エラーを返す 終了する場合 終了関数
- 上記の疑似コードでは、プログラムはアドレスにアクセスする前にアドレスの有効性をテストします。これにより、間違ったアドレスが渡された場合でもプログラムを続行できます。
バグに関するユーモアと有名な引用
- 「それはバグではありません、機能です！」 (英語の「バグではありません、機能です」より)。 – ソフトウェア開発者からユーザーへの頻繁な応答。
- 「すべての重要なプログラムには少なくとも 1 つのバグがあります」 (英語の「すべての重要なプログラムには少なくとも 1 つのバグがある」より) – コンピューティングに適用されるマーフィーの法則から引用 (以下の外部リンクを参照)
- 「人間がミスをするのは当然ですが、実際の災害にはコンピューターが必要です。」
- 「ソフトウェアにバグがなくなったら、通常はそのソフトウェアは時代遅れになります。」
ビデオゲーム
ビデオ ゲームにおけるバグという用語は、想定される動作過程におけるエラーを主な意味とします。バグの最終結果は、その強度に応じて、同じ不都合を引き起こすことはありません。一人称シューティング ゲームでプレイヤーの手が壁を越えても、ロールプレイング ゲームのメイン クエストを完了できないことほど迷惑なことはありません。
バグの存在はマイナス点をもたらすだけではありません。
- 実証されたバグの検索と修正により、現在まで知られていない他のバグの修正やソース コードの最適化が可能になることが多く、これはプレイヤー (ゲームプレイの改善) と開発者(定期的なテクニカル サポート) にとって非常に有益です。ゲームは名声を保証します)。
- バグがあるにも関わらずゲームが異常に人気になると、さまざまなツールを使用してこれらのバグを修正できる非常に多作なコミュニティが発足することがよくあります。この現象を最も象徴するゲームは間違いなくFallout 2です。
- 一部のバグは、多かれ少なかれ悪意を持ったプレイヤーに利益をもたらす可能性があります。ネットワーク上 (インターネットまたはローカル ネットワーク上) でプレイ可能なゲームでは、悪用可能なバグは 2 つの側面があります。それらはフェア プレイ (特に主観的なシューティング ゲーム) を破壊する原因となるか、または目覚ましい進歩を可能にするかのいずれかです。その事実は不正行為に似ています。
- Speedrun コンテストでは、ゲームやシーケンスをできるだけ早く終了するために、特定のバグが非常に有益です。
「バグ」という用語には、 「バグ」という名前の人気により、あまり一般的には使用されない他の概念も含まれます。一部のエラーはバグではなく見落としとして名前を付けることが賢明です。
特定の 4 種類のバグ
- マンデルバグ
- シュレディンバグ
- ハイゼンバグ
- ボーアバグ