バグ報告の一週間

ソフトウェアを日常的に使用し、注意を払っていれば、バグに遭遇したことに気づくことはよくあります。つまり、ソフトウェアが本来行うべきこと（または行うべきでないこと）をしなかった（またはした）ということです。このような場合、ほとんどの人は、ソフトウェア開発者の無能さを近くにいる人に愚痴り、その後、同じバグに繰り返しつまずきながら、やっていたことを続けます。バグの報告を考えるのは少数派であり、もし報告を考えたとしても、時間がかかりすぎるとか、馬鹿らしく見えるかもしれないという理由で、しばしば実行できません。 あまりにも多くの人がバグを報告しないのは残念です。まず、驚くほど少ないバグが一人に影響するだけです。誰かがバグを報告する頃には、それは他の何百、何千人もの人々に影響を与えている可能性があります。私たちは皆フリーローダーであるわけにはいきません。誰かが飛び込んでバグを報告しなければなりません。次に、バグはしばしばソフトウェア開発者にとって馴染みのないコンテキストで現れます¹。最も明白なのは、私たち全員がわずかに異なるソフトウェアのインストールを持っており、それらのバリエーションが奇妙な効果を引き起こす可能性があることです。あまり明白でないのは、ユーザーがしばしば、その作成者によって想像もされなかった方法でソフトウェアを使用しており、以前テストされていなかった操作の組み合わせが正しく機能しない²ということです。どちらにしても、私たちが遭遇するのと同じバグにソフトウェアの開発者が遭遇すると仮定することはできません。多くの場合、私たちがバグを報告しなければ、開発者はその存在を知ることさえできません。 他人のソフトウェアでバグを報告することは、自分のコードでバグを見つけて修正することとは異なります。なぜなら、私たちはそれらの他のシステムをはるかに理解していないからです。自分のコードのバグに対する私の混乱の感覚は、他のシステムを使用するときに増幅されます。私は実際に予期しない動作を見ていると確信している度合いが低く、原因が何であるかについての確信度も低く、提案する修正に対する信頼度も通常より低いです。これは、重要なトレードオフを認識しなければならないことを意味します。馴染みのないシステムでのバグの原因を完全に理解することは、しばしば合理的な時間の投資を超えています。しかし、「それは機能しない」と言うだけでは、誰もバグを再現すること、ましてや修正することは期待できません。その中間に、バグ報告者がバグを修正するために開発者が使用できる十分なバグレポートを生成するために費やす時間を最小限に抑えるスイートスポットがあります。 バグ報告が毎朝私をベッドから起こしてくれるとは言いませんが、そうすることにいくらかの義務を感じています。私はオープンソースソフトウェアの存在から多大な恩恵を受けており、バグ報告はその貢献の一部です。何年もそうしてきた今、時間や評判の面で、バグ報告はかつてよりもはるかに恐れなくなりました。 この記事では、8月の最初の週に私がさまざまなオープンソースソフトウェアに対して報告したバグを見ていきます。これはほとんど正常な週ではありません。なぜなら、私は新しいラップトップでそれを始めたからです。これは、私が通常よりも多くのバグに遭遇することをほぼ保証していました。しかし、すぐにわかるように、それは私が遭遇したバグの唯一の源ではありませんでした。私の報告の一部はバグの修正につながり、一部はそうではありませんでした。明らかに前者に期待していますが、オープンソース開発者は私のバグ報告を調査する、ましてや修正する義務はありません。私が使用しているソフトウェアについてある程度の詳細を知っている（しかし、常にそうとは限らない）私のような人が、バグだと信じているものに遭遇したときに何が起こるかを見るのは役立つと思います。私は、プロセスに不可欠であると思われる、私が経験した混乱の多くを記録しようとしました。驚くことではありませんが、私が書いたことの多くは、バグの影響を理解し、その原因を調査しようとする私の試みに関連しています。私のバグ報告と開発者とのやり取りが、バグの理解において私と彼らの両方にとってどれほど重要な役割を果たしたかの感覚も得られることを願っています。私のバグ報告は品質が大きく異なっただけでなく、バグの原因や良い修正方法についての私の最初の推測が間違っていることもかなり頻繁にありました。私が遭遇した順序でおおよそこれらのバグを提示します。なぜなら、あなたが見るように、そうでなければ明らかではないよりも多くの重複があるからです。 A new laptop 5年間の使用を経て、私の古いThinkpadは寿命に達しました。バッテリー寿命は約半分に低下し、一度以上不便な時に電源が切れてしまい、バッテリーをさらに損傷しました。さらに、その2つの物理コアは、現代のソフトウェアが要求する負荷に対応できなくなり、私はますます指をくわえて待つことが多くなりました。私は19年間Thinkpadを使用してきました³。そして最近まで、これからも使い続けるだろうと思っていました。しかし、Frameworkのモジュラーアプローチは、私にとってより環境的に持続可能なハードウェアのアプローチのように思え、同等に優れており、私のサポートに値するものだったので、苦労して稼いだお金で購入しました。最初の世代のFrameworkがOpenBSD（私の好みのオペレーティングシステム）でサポートされていることは知っていましたが、新しくリリースされた第2世代（私が購入したもの）も動作することを願っていました。しかし、経験から、新しくリリースされたハードウェアは、しばらくの間OpenBSDで完全に動作しない傾向があることを知っていました。 Video and keyboard oddities BIOSで「セキュアブート」をオフにした後、OpenBSDインストーラーは起動し、正しく機能しました。しかし、インストーラーはテキストのみであり、ハードウェアへの要求は比較的少ないです。本当のテストは、「フル」インストールに再起動したときに起こるだろうとわかっていました。幸いなことに、それはかなりうまくいったように見え、私は使い慣れたすべてのパッケージのインストールを開始しました。すぐに、注文したUKキーボードで押しているキーが、画面に表示されているものと一致しないことがあることに気づきました。OpenBSDでこれが起こったことは覚えていないので、wsconsctlがキーボードエンコーディングを教えてくれることに気づくまで少し時間がかかりました。Frameworkでは、次のように表示されました。 $ doas wsconsctl keyboard.encoding keyboard.encoding=unknown_0 私のデスクトップでは、対照的に、keyboard.encoding=ukです。その後、キーボードエンコーディングをUKに強制しようとしましたが、すぐにカーネルパニックに陥りました。 $ doas wsconsctl keyboard.encoding uk uvm_fault(0xfffffd87b4e6a780, 0x8, 0, 1) -> e kernel: page fault trap, code=0 Stopped at wskbd_load_keymap+0x33: movl 0x8(%rax),%ecx ... これは良いニュースではありません。カーネルがクラッシュしたことを意味します。私はかなり驚いたので、再起動しましたが、何も入力する前にカーネルパニックに遭遇しました。もう一度再起動し、ターミナルプロンプトに到達し、キーボードエンコーディングを設定しようとしました。すぐに別のクラッシュを引き起こしました。もう一度再起動し、数秒の使用後（キーボードエンコーディングを設定しようともせずに）別のカーネルパニックに遭遇しました。この時点で私は少し困惑しました。少なくとも2つの別々のバグに遭遇しているようでした。キーボードエンコーディングの設定は、確実に即時のカーネルパニックを引き起こしました。しかし、私は理解できない別の理由でカーネルパニックに遭遇していました。その後、キーボードエンコーディングを設定した後に意図的に別のパニックを引き起こし、カーネルの出力を写真に撮り、OpenBSDのバグメーリングリストにバグレポートを提出しました。その本文は次のとおりです。 「Framework 12世代Intelラップトップを入手しました。それはある程度動作しますが、-currentで定期的にカーネルパニックやその他の奇妙な問題が発生します。まだ原因を特定できていませんが、uvm_faultsが頻繁に発生しているようです。例えば、キーボードエンコーディングの設定がuvm_faultを引き起こします。 $ doas wsconsctl keyboard.encoding=uk uvm_fault(0xfffffd87b4e6a780, 0x8, 0, 1) -> e （カーネルの出力のスクリーンショット）」