プログラミング

バグ報告の一週間

6 pointsby luu2026年9月4日1 コメント

要約

この記事は、ソフトウェアのバグを報告することの重要性について論じています。多くの人がバグに遭遇しても報告を怠る現状を指摘し、開発者が見つけにくい環境要因や、ユーザーのユニークな使用方法がバグの原因となることを説明しています。著者は自身の経験に基づき、オープンソースソフトウェアへの貢献としてバグ報告を行うことの意義と、その過程での試行錯誤を共有しています。

全文翻訳

バグレポートの一週間

ソフトウェアを日常的に使用しており、注意を怠らなければ、バグに遭遇したことに気づくことはよくあります。つまり、ソフトウェアが本来行うべきこと（または行うべきでなかったこと）をしなかった、あるいは行ったということです。このような場合、ほとんどの人は、ソフトウェア開発者の無能さについて近くの人に不平を言い、その後、しばしば同じバグに繰り返しつまずきながら、やっていたことを続けます。バグを報告することを考えるのは少数派であり、もし報告することを考えても、時間がかかりすぎるとか、愚かに見えるかもしれないという理由で、実行できないことがよくあります。

これほど多くの人がバグを報告しないのは残念です。第一に、驚くほど少ないバグが一人に影響するだけです。誰かがバグを報告する頃には、それは何百、何千人もの他の人々に影響を与えている可能性があります。私たち全員がフリーライダーであるわけにはいきません。誰かが飛び込んでバグを報告しなければならないのです。第二に、バグはしばしばソフトウェア開発者にとって馴染みのないコンテキストで現れます¹。最も明白なのは、私たち全員がわずかに異なるソフトウェアのインストールを持っており、それらのバージョンが奇妙な影響を引き起こす可能性があるということです。あまり明白でないのは、ユーザーがしばしば、その作成者が想像もしなかった方法でソフトウェアを使用するため、以前テストされていなかった操作の組み合わせが正しく機能しないことがあるということです²。いずれにしても、開発者が私たちと同じバグに遭遇するとは限りません。多くの場合、私たちがバグを報告しなければ、開発者はその存在を知ることもないでしょう。

他人のソフトウェアのバグを報告することは、自分のコードのバグを見つけて修正することとは異なります。なぜなら、私たちはそれらの他のシステムをはるかに理解していないからです。自分のコードのバグに対する混乱の感覚は、他のシステムを使用する際には増幅されます。予期しない動作を見ているという確信は薄れ、原因が何であるかについての確信は薄れ、提案する修正に対する信頼は通常よりも低くなります。これは、重要なトレードオフを認識しなければならないことを意味します。馴染みのないシステムにおけるバグの原因を完全に理解することは、しばしば合理的な時間の投資を超えています。しかし、「動作しない」と言うだけでは、誰もそれを再現すること、ましてや修正することは期待できません。その中間に、バグ報告者が開発者がバグを修正するために使用できる十分なバグレポートを生成するために費やす時間を最小限に抑える「スイートスポット」があります。

バグレポートのために毎朝起きるというわけではありませんが、そうすることに一種の義務感を感じています。私はオープンソースソフトウェアの存在から多大な恩恵を受けており、バグ報告はその貢献の一部です。何年もそうしてきた今、時間や評判の面で、バグ報告はかつてよりもはるかに恐れなくなりました。

この記事では、8月の最初の週に私が様々なオープンソースソフトウェアに対して報告したバグを見ていきます。これは決して普通の週ではありません。なぜなら、新しいラップトップから始めたからです。これは、通常よりも多くのバグに遭遇することをほぼ保証するものでした。しかし、すぐにわかるように、それが私が遭遇したバグの唯一の原因ではありませんでした。私の報告の一部はバグの修正につながりましたが、一部はそうではありませんでした。明らかに前者（修正）を期待していますが、オープンソース開発者は私のバグレポートを調査する義務、ましてや修正する義務はありません。

私のような、時々、しかし決して常に、使用しているソフトウェアについてある程度の詳細を知っている人が、バグだと信じているものに遭遇したときに何が起こるかを見るのは有益だと思います。プロセスに不可避な部分であると思われる混乱の多くを、覚えている限り記録するようにしました。驚くことではありませんが、私が書いたことの多くは、バグの影響を理解し、その原因を調査しようとする私の試みに関連しています。また、開発者とのやり取りが、バグの理解において、私と彼らの両方にとってどれほど重要な役割を果たしたかを感じていただければ幸いです。私のバグレポートの質は大きく異なっただけでなく、バグの原因や良い修正方法についての私の最初の推測が間違っていることも少なくありませんでした。

私が遭遇した順序でおおよそこれらのバグを提示します。なぜなら、あなたが見るように、そうでなければ明らかでないよりも多くの重複があるからです。

新しいラップトップ

5年間の使用の後、私の古いThinkpadは実用的な寿命の終わりに達しました。バッテリー寿命は約半分に低下し、一度以上、不便な時間に電力が尽きてしまい、バッテリーをさらに損傷させました。さらに、その2つの物理コアは、現代のソフトウェアが要求する負荷にはもはや対応できず、私が待つ時間がますます増えました。私は19年間Thinkpadを使用してきました³。そして最近まで、今後もそうし続けるだろうと思っていました。しかし、Frameworkのモジュラーアプローチは、私にとってより環境的に持続可能なハードウェアのアプローチのように思え、同等に優れており、私のサポートに値するものだったので、苦労して稼いだお金で購入しました。

第一世代のFrameworkはOpenBSDでサポートされている（私の選択したオペレーティングシステム）ことを知っており、最近リリースされた第二世代（私が購入したもの）も動作することを願っていました。しかし、経験から、新しくリリースされたハードウェアは、しばらくの間OpenBSDで完全に動作しない傾向があることを知っていました。

ビデオとキーボードの奇妙な挙動

BIOSで「セキュアブート」をオフにした後、OpenBSDインストーラーは正しく起動して機能しました。しかし、インストーラーはテキストのみであり、ハードウェアへの要求は比較的少ないです。本当のテストは、「フル」インストールに再起動したときに起こるだろうとわかっていました。幸いなことに、それはかなりうまくいったようで、私は使い慣れたすべてのパッケージのインストールを開始しました。

注文したUKキーボードで押したキーが、画面に表示されるものと一致しないことにすぐに気づきました。OpenBSDでこのようなことが起こったことは一度もなかったと思いますが、wsconsctlがキーボードエンコーディングを教えてくれることに気づくまで少し時間がかかりました。Frameworkでは次のように表示されました。

$ doas wsconsctl keyboard.encoding
keyboard.encoding=unknown_0

対照的に、私のデスクトップでは keyboard.encoding=uk です。次に、キーボードエンコーディングをUKに強制しようとしましたが、すぐにカーネルパニックが発生しました。

$ doas wsconsctl keyboard.encoding
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_faultが頻繁に発生しているようです。例えば、キーボードエンコーディングを設定するとuvm_faultが発生します。
$ doas wsconsctl keyboard.encoding=uk
uvm_fault(0xfffffd87b4e6a780, 0x8, 0, 1) -> e
この特定のパニックのスクリーンショットは https://postimg.cc/nM5rLGY6 です。

ハードウェアの一部がまだ完全にサポートされていないだけだと疑っています。dmesgには通常の数よりも多くの「not configured」があり、私には新しいもの（おそらくPCI関連？）も含まれています。
0:31:5: mem address conflict 0xfe010000/0x1000

これは意図的に短いバグレポートです。まず、私が第二世代FrameworkでOpenBSDを試した最初の人である可能性が非常に高かったため、すべてが完璧に動作することを期待すべきではないことを知っていました。第二に、パニックを確実に引き起こす方法（キーボードエンコーディングの設定）を1つ記録し、他の原因もあるようだと漠然と述べました。後者について可能性のある提案をしました（後に無関係であることが判明しました）。しかし、私はOpenBSD開発者が言うことを待っていました。なぜなら、彼らは私が持っていないFramework上のOpenBSDの可能性のある状態について文脈を持っているかもしれないからです。

3時間以内に、著名なOpenBSD開発者であるJonathan Grayが返信しましたが、私が経験しているパニックをすぐに解決することはできませんでした。

その間、継続的に再起動することで、グラフィックの破損とパニックの間の断続的な相関関係に気づき始め、それをレポートの更新に使用しました。

ランダムなパニックについても少し理解し始めています。Xが開始されてすぐに発生するようです。マウスが奇妙な色の2インチ四角形 (!) として表示されることがあります。その後、数秒しか持続しません。これによって表示されるパニックは一度だけあり、単に次のように言っていました。
uvm_fault(0xffffffff822f0400, 0xfff80001660014, 0, 1) -> e
drm: Global state not read locked
drm: Global state not read locked

Jonathanは再び迅速に修正案を提示しました。私はその修正を適用しました（OpenBSDをソースからビルドする方法に関する基本的な知識が必要です）。そして、10回の起動後もパニックを引き起こせなければ、問題はほぼ解決したと見なすことにしました。10回の成功した再起動の後、私は次のように報告できました。

このパッチを含むカーネルは、現在10回の再起動を乗り越えました（以前は3回に1回くらいの頻度でパニックが発生していました）。そのため、効果は本物である可能性が非常に高いと思います。ありがとうございます！

その修正は、最初のバグレポートから24時間も経たないうちに、OpenBSDにコミットされました！

残念ながら、キーボードエンコーディングの問題は修正がかなり難しいことが判明しました。別の頻繁なOpenBSD開発者であるMiod Vallatは、キーボードエンコーディングのパニックを防ぐメカニズムを提案しましたが、問題はそこまで進むべきではなかったと指摘しました。別の開発者が、デバッグパッチを提案して私にプライベートメールで送ってきましたが、有用なものは何も示されませんでした。その後、私はOpenBSDカーネルがキーボードエンコーディングをどのように処理するかを2〜3時間かけて調べました。その複雑さに驚きました！カーネルは、さまざまな貧弱なハードウェアに対処するためのヒューリスティックを使用する必要があり、カーネルセットアップの理想的ではない早い段階でUSBキーボードをサポートする必要があります。私がここで何が起こっているかを理解できる能力があるとしても（それは保証されていません！）、意味のある貢献をするには長い時間がかかるように思われます。驚いたことに、同じラップトップを持つ別のOpenBSDユーザーが、米国キーボードを使用していますが、キーボードエンコーディングで問題は発生していません。Framework UKキーボードまたはBIOSに問題がある可能性がありますか？可能性はありますが、おそらくそれほど高くはありません。いずれにしても、執筆時点では、キーボードエンコーディングは自動検出されず、手動で設定しようとするとカーネルパニックが発生します。

これらの2つのバグで興味深いのは、キーボードエンコーディングのパニックは修正が簡単で、他のパニックは修正が難しいと想定していたことです。代わりに、その逆が判明しました！これは関係する開発者のいずれかに対する非難ではありません。ソフトウェアの一部を大まかにしか理解していない私たちにとって、特定のバグの原因を特定し修正するのがどれほど難しいかを正確に推測するのは困難です。

クリックパッドの誤認識

ビデオの奇妙な挙動に関する私のレポートの一部として、JonathanはOpenBSDカーネルを拡張して、Frameworkの以前に遭遇したことのないハードウェアの一部を識別しました（おそらくこのパッチで）。これにより、トラックパッドがカーネルによって識別される方法が変更されました。驚いたことに、関連する標準は「トラックパッド」と「クリックパッド」を区別しています。クリックパッドからタッチパッドに変更されました。突然、私がトラックパッドと呼ぶもの（関連標準では「クリックパッド」と呼ばれる）の右マウスボタンが機能しなくなりました。

これについて何か知っていると思われる開発者にメールを送りましたが、何も返信がなかったので、自分で調査することにしました。私は長年OpenBSDカーネルにいくつかのマイナーなデバイス貢献をしてきたので、少なくとも問題がどこにあるのかを突き止められるかもしれないと思いました。簡単なgrepで、次のコード（hidmt.c内）がクリックパッドとタッチパッドを区別する場所であることがわかりました。

/* find whether this is a clickpad or not */
if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS, HUD_BUTTON_TYPE), 
  mt->sc_rep_cap, hid_feature, ∩, NULL)) {
    d = hid_get_udata(rep, capsize, ∩);
    mt->sc_clickpad = (d == 0);
} else {
  /* if there's not a 2nd button, this is probably a clickpad */
  if (!hid_locate(desc, dlen, HID_USAGE2(HUP_BUTTON, 2), 
    mt->sc_rep_input, hid_input, ∩, NULL))
      mt->sc_clickpad = 1;
}

案の定、mt->sc_clickpad=1を強制すると、以前の動作に戻りました。私の最初の仮説は、ヒューリスティックが間違っているのではないかということでした。そこで、さまざまなカーネルファイルで DEBUG 変数をオンにし始めました。これは、hid.cでUSBHID_DEBUGをオンにしたときにコメディを引き起こしました。コンソールへの出力が多すぎて、15分経ってもマシンが起動し終わらなかったのです！

そのルートがうまくいかなかったので、上記の if/ else にいくつかの printf を追加してカーネルを再実行しました。これにより、else ブランチが実行されていることが示されました。私のクリックパッドにはいくつのボタンがありますか？hidms.cからコードをコピー＆ペーストすることで、4つのボタンが報告されていることを発見しました。これは私が全く期待していなかったものであり、上記の「ボタンが2つない場合」というヒューリスティックを無効にします。

その後、解決策を探して1時間ほどさまよいましたが、libinputに対するこのプルリクエストを見つけました。これは、LinuxではFrameworkのタッチパッド（私が今気づいたのは、PixArt Imaging PIXA3854であること）に、カーネルドライバーが「クワーク」（つまり、そのデバイスの特別なケース）と呼ぶものがあることを示していました。この時点で、問題に費やした時間は約2時間でした。

これは、OpenBSDにも同様のクワークを追加する必要があることを示唆していました。その後、IMTデバイスのベンダーIDとプロダクトIDがOpenBSDカーネルのどこに格納されているかを見つけるのにさらに2時間ほどかかりました。私は円を描いて回っていましたが、hidmt.cがクリックパッド/タッチパッドテストを実行していましたが、imt.cがベンダーIDとプロダクトIDを確認するのに適切な場所であることに気づきました。これが最終的に私がたどり着いたものです。

struct i2c_hid_desc *hid_desc = &sc->sc_hdev.sc_parent->hid_desc;
if (hid_desc->wVendorID == 0x093A && hid_desc->wProductID == 0x274)
  // ...この時点でPIXA3854があります

それが完了すると、残りはすぐに解決し、少しのテストとクリーンアップの後、私はOpenBSDの技術メーリングリストにメールとパッチを送信しました。

Frameworkのクリックパッド（PixArt PIXA3854）は、4つのボタンがあるとアナウンスしており、「ボタンが2つ以上ならタッチパッド」という通常のヒューリスティックを無効にします。タッチパッドとして識別されると、右マウスボタンが機能しなくなります（それ以外は、操作上のクリックパッドとタッチパッドの違いはわかりません！）。Linux/libinputにもこのデバイス用のクワークがありますが、彼らは単に2番目のボタンを無効にしています。

メール末尾のパッチは、PIXA3854を検出し、クリックパッドとして識別されるように強制するクワークを追加します。カーネルのこれらの部分に私がどれほど不慣れであるかを言うのは控えめな表現です。このパッチは私には機能しますが、これがこの特定のデバイスで「右マウスボタンが機能しない」という問題を解決する最良の方法、あるいは許容できる方法であるかどうかはわかりません！

最初の段落はバグ⁵を明確に説明しており、他の人がそれをどのように修正したかも示しています。2番目の段落は、私の修正は私には機能しましたが、それが問題解決の最善の方法である（あるいは、おそらく正しい方法である）という完全な確信はなかったことを明確にしています。

そしてもちろん、この問題にあまりにも早く飛びついてしまったことに気づきました。OpenBSDのバグメーリングリストを、誰かがこの問題に遭遇したかどうかを確認するためにチェックしましたが、技術メーリングリスト自体はチェックしていませんでした。案の定、Joshua Stein（第一世代FrameworkでOpenBSDをうまく動作させた人物）は同じ問題に遭遇しており、修正案も提案していました！確かに、その修正は受け入れられていないようであり、最後のメッセージは私が提案したような修正の方がおそらく良かったことを示唆しています。しかし、それでも、なんて愚かなんだ私は。私のパッチを作成するのにかかった4〜5時間が完全に無駄にならなかったのは純粋な運でした！バグ修正の第一法則を忘れました：誰かがすでに問題に遭遇し、おそらく修正さえしているかどうかを注意深く確認することです。確認しましたが、あまりにも早く確認しました。

パッチを投稿した後、OpenBSDカーネルのこの部分に詳しい人物からオフリストで連絡がありました。関連仕様を注意深く読んだ後、彼は私が作成したデバイスベースのクワークを回避する、より一般的なパッチを考案しました。すぐに彼のパッチが私にも機能することを確認し、私が判断できる限り、既存のデバイスを壊さないように見えました。執筆時点では、私たちのどちらのパッチもOpenBSDに含まれていませんが、どちらかがすぐに含まれることを願っています。

壊れたiCalendarファイル

Frameworkを設定している間、私はThunderbirdをインストールしました。これはカレンダーアプリとしてのみ使用しています（メールにはneomuttを使用しています）。そして、使用している2つのiCalendar（.ics）ファイルをインポートしました。私の市からの小さなカレンダー（ゴミ箱を出す時期を教えてくれる）は問題なくインポートされました。しかし、10年以上にわたる3600件のエントリを持つ私のメインカレンダーファイルは動作しませんでした。インポートはエラーを発生させませんでしたが、エントリも表示されませんでした。数回試して、後日また試そうと思い、脇に置きました。

数日後、デスクトップのOpenBSDマシンでパッケージをアップグレードしたところ、メインカレンダーもそこで表示されないことにすぐに気づきました。簡単な調査で、Thunderbirdがバージョン91.11.0から102.1.0にアップグレードされたことがわかりました。カレンダーファイルがアップグレードで破損したのではないかと思いましたが、git履歴を簡単に確認しても、明白なものは何もありませんでした。

次に、ThunderbirdがiCalendarファイルを摂取する際に、よりうるさくなったのではないかと推測しました。「iCalendarからiCalendarへの変換」プログラムを探し、それが私のファイルを「アップグレード」してくれることを期待しました。すぐにPythonのicalendarライブラリを見つけました。しかし、それも私のファイルをインポートできませんでした。

Traceback (most recent call last):
  File "/tmp/conv.py", line 4, in 
    Calendar.from_ical(d)
  File "/usr/local/lib/python3.9/site-packages/icalendar/cal.py", line 383, in from_ical
    vals = factory(factory.from_ical(vals))
  File "/usr/local/lib/python3.9/site-packages/icalendar/prop.py", line 525, in __init__
    tzid = tzid_from_dt(start)
  File "/usr/local/lib/python3.9/site-packages/icalendar/parser.py", line 54, in tzid_from_dt
    if hasattr(dt.tzinfo, 'zone'):
AttributeError: 'datetime.date' object has no attribute 'tzinfo'

次にRustのicalendarライブラリを見ましたが、それは（記憶によれば）入力と同一の出力を生成したため、Thunderbirdは結果をインポートできませんでした。

少し神経質になり始めました。私のカレンダーは私の生活の進め方において非常に重要です！次に、iCalendar変換ができるOrageを使ってみましたが、カレンダー内のあらゆる種類のことに異議を唱えました。次に、長年使用していたkOrganizerを試しましたが、クラッシュし始めました。残念ながら、カレンダーをインポートしようとしたときにセグメンテーション違反を起こしました。次にGNOME Calendarを試しましたが、これはカレンダーを正しくインポートしただけでなく、驚くほど速くインポートしました。勝者が見つかったと思いました！次にGNOME Calendarを少し探索しましたが、XFCEで通知をどのように表示するかを知りませんでした（予定を入れるには複数の警告が必要です！）。また、異なるタイムゾーンで予定をどのように作成するかについても確信が持てませんでした（この機能があることは確かですが、すぐにわかりませんでした）。

この時点で、Pythonのicalendarライブラリをもう一度調べるべきだと思いました。その内部を調べ始め、見たトレースバックの行の周りにprint文を配置しました。すぐにコード内の次のコメントに気づきました。

# does not support different timezones for start and end

それが手がかりとなり、その時点の日付をprint文で出力しました。トレースバックの前に、単一行が出力されました。

2022-06-06

iCalendarファイルはプレーンテキストなので、どのエントリに対応するかを理解するのに一瞬しかかかりませんでした（プライバシー上の理由から、いくつかの詳細を省略しています）。

BEGIN:VEVENT
UID:4ABCDEF
DTSTAMP:20220531T190736Z
DTSTART;VALUE=DATE:20220606
DTEND;VALUE=DATE:20220608
SUMMARY:Blah blah.
FREEBUSY;FBTYPE=FREE:20220606/20220608
TRANSP:TRANSPARENT
END:VEVENT

その単一のエントリを削除したところ、Thunderbirdは私のカレンダーファイル全体をインポートできるようになりました！メールを素早く検索したところ、このiCalendarエントリはホテルの部屋を予約したときに私に送られてきたことがわかりました。古いバージョンのThunderbirdはこれを問題なくインポートし、私のメインカレンダーファイルにコピーしていましたが、新しいThunderbirdはエントリをインポートできませんでした（単独でも、メインカレンダーの一部としても）。

この時点で、原因を特定しましたが、なぜ問題を引き起こしていたのでしょうか？iCalendarファイルの形式について何も知らなかったので、隣接するエントリを調べました（プライバシー上の理由から、いくつかの詳細を省略しています）。

BEGIN:VEVENT
CREATED:20220513T220740Z
LAST-MODIFIED:20220513T220751Z
DTSTAMP:20220513T220751Z
UID:5BCDEG
SUMMARY:Blah blah
DTSTART;TZID=Europe/London:20220606T143000
DTEND;TZID=Europe/London:20220606T180000
TRANSP:OPAQUE
END:VEVENT

icalendarコードのコメントと隣接するエントリの間で、答えが飛び出してきました。問題のエントリには、DTSTARTエントリにタイムゾーン情報が含まれていませんでした！

その後、Thunderbirdのバグをどこに報告できるかを見つけるのに少し時間がかかりました。結局、私は「Calendar」と呼ばれる別のコンポーネントを使用していたことがわかりました。最終的に、以下のレポートを提出しました。

Thunderbirdは以前、DTSTARTにタイムゾーンがないicsファイルをインポートできましたが、v102にアップグレードしたところ、インポートできなくなりました。数ヶ月前に予約サイトから受け取った例を以下に示します。
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Avvio//NONSGML Convert//EN
BEGIN:VEVENT
UID:4ABCDEF
DTSTAMP:20220531T190736Z
DTSTART;VALUE=DATE:20220606
DTEND;VALUE=DATE:20220608
SUMMARY:Blah blah.
FREEBUSY;FBTYPE=FREE:20220606/20220608
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR
興味深いことに、Thunderbirdは以前はインポートできただけでなく、タイムゾーンを追加せずに私の「メイン」カレンダーにコピーしていました。そのため、Thunderbird v102が読み込めない「マージされた」カレンダーがありました。しかし、Thunderbirdは読み込めない理由を全く示しませんでした。カレンダーエントリが全くありませんでした。py-icalendarも同じDTSTART値を解析できなかったため、最終的に問題のあるエラーを特定できました！

期待される結果：
IMHO、元のicsファイルは間違っていますが、Thunderbirdが以前受け入れていたため、Thunderbirdによって作成されたと想定しているicsファイルを持っている他の人々もいるでしょうが、無効な値がインポートされています。

理想的には、Thunderbirdは解析できないicsファイルに遭遇した場合、少なくともユーザーに明示的に警告するべきです。この（確かに珍しい）タイムゾーンの欠落の場合、ユーザーにどのタイムゾーンを希望するか尋ねるか、（これは明らかな問題がありますが！）ローカルタイムゾーンにフォールバックすることもできます。

このファイルをインポートする問題は、すぐに他の人によって確認され、より知識のある人々が修正方法を理解するのに役立つ簡単なテストケースでバグを報告できたことを嬉しく思いました。

しかし、数日後、私はしつこい考えを払拭できませんでした。タイムゾーン情報の欠落が本当に原因だったのでしょうか？私が使用した証拠は、後から考えるとかなり状況的でした。もう一度メインのiCalendarファイルを見直したところ、DTSTARTエントリにタイムゾーンがない他のエントリが多数ありました。明らかに、私の最初の評価は早すぎました！

そこで、最初にやるべきだったことを行い、入力から行を削除して、Thunderbirdが結果をインポートできるかどうかを確認し始めました。すぐに、問題は実際にはFREEBUSY行⁷であることがわかりました。その行を削除すると、Thunderbirdはエントリをインポートできるようになりました。

この時点で、少し恥ずかしながら、元のバグレポートは誤解を招くものだったことに気づきました。このような時、私のエゴはこっそり逃げて誰も私の間違いに気づかないことを願うように誘惑しますが、それは私のレポートを調べている人々にとって公正ではありません。そこで、私は新しい発見でレポートを改訂し、バグのタイトルを更新しました⁸。その後、Thunderbird開発者は調査を進め、バグの原因を徐々に解明し、修正をコミットしました。私はいつもそうするように（時々忘れますが）感謝の意を表明するためにバグレポートを更新しました。自分に直接関係のない問題の解決に他の人の努力を認めることは重要だと感じています。

振り返ってみると、このバグの良いテストケースに偶然たどり着けたのは幸運だったと思います。PythonのiCalendarライブラリも同じエントリでつまずかなかったら⁹、どうしたかわかりません。Thunderbirdの内部に飛び込もうとはしなかったでしょう。おそらく、カレンダーファイルを二分探索しようとしたかもしれませんが、それはかなりの労力がかかるでしょう。

quodlibetとlibsoup[23]

数年間、私はquodlibetを音楽プレーヤーとして使用してきました。その理由は、私の好みのリスニングスタイルによく合う優れた「アルバムスキップ」機能があるからです。Thunderbirdの不調を引き起こしたのと同じアップグレードの後、quodlibetが「libsoup2とlibsoup3を同じプロセスで使用することはサポートされていません」と不満を言ってロード時に中止するようになりました。libsoupという言葉を聞いたこともなく、確かに2つの別々のバージョンがインストールされているとは知りませんでした！

私はOpenBSDのportsシステム¹⁰を素早く調べました。quodlibetはlibsoup2に直接実行時依存関係があり、libsoup3に変更するという明白なことをしました。驚くべきことに、バイナリパッケージがどのように影響するかはわかりませんでしたが、これでうまくいくように見えました。したがって、私のその後のバグレポートは、私の修正が正しいとは確信していないことを明確にしました。

幸いなことに、RUN_DEPENDSをlibsoupからlibsoup3に更新するだけで問題が解決するようで、quodlibetが動作するようになります（ただし、これがなぜ解決するのかについては少し不確かです。quodlibetがRUN_DEPENDSの影響をどこで拾うのかわからないからです。しかし、それはおそらく私の無知でしょう）。これを理解している人が、この変更が妥当かどうかを確認していただけると幸いです！パッチはメールの最後にあります。

案の定、すぐにStuart Hendersonによって、私の「修正」は直接的な影響を与えていないことが確認されました。Stuartは、portsのquodlibetのバージョンを4.4.0から4.5.0にアップグレードすることで、libsoupの問題を回避できることに気づきました。残念ながら、quodlibet 4.5.0は私にとっては半分の機能しかありませんでした。ほとんどのアクションで以下のエラーが発生しましたが、quodlibetは他の点では動作しました。

AttributeError: 'gi.repository.Soup' object has no attribute 'URI'
------
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/quodlibet/util/cover/manager.py", \ 
line 120, in failure  run()
  File "/usr/local/lib/python3.9/site-packages/quodlibet/util/cover/manager.py", \ 
line 136, in run  provider.fetch_cover()
  File "/usr/local/lib/python3.9/site-packages/quodlibet/util/cover/http.py", line \ 
86, in fetch_cover  if not self.url:
  File "/usr/local/lib/python3.9/site-packages/quodlibet/ext/covers/discogs.py", \ 
line 63, in url  artist = escape_query_value(artists)
  File "/usr/local/lib/python3.9/site-packages/quodlibet/util/cover/http.py", line \ 
111, in escape_query_value  return Soup.URI.encode(s, '&')
  File "/usr/local/lib/gi/module.py", line 123, in \ 
__getattr__  raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Soup' object has no attribute 'URI'

最初は、誰かが同じ問題を経験している場合に備えて、簡単なレポートを送信しました。その後、数日間問題を忘れました。戻ってきたとき、quodlibetはまだ同じ問題を抱えていました。

もう少し注意深く見たところ、Pythonのトレースバックが問題の可能性のある手がかりを与えてくれました。そして案の定、cover/http.pyにimport Soup.URIを追加するだけで、継続的なトレースバックは見られなくなりました。数分後、私はOpenBSDポート用の「本格的な」パッチを作成し、メーリングリストに提出しました。

この時点で私はかなり得意になっていました。問題を非常に簡単な方法で解決したからです！幸いなことに、より注意深いStuartは、私の「修正は問題を隠しているだけ」であることを指摘しました¹⁴。実際には、別のサブモジュールが使用される原因となるエラーを導入していました。Pythonにはかなり慣れていますが、quodlibetやgobjectとその仲間たちの内部を見たことはないと思います。私のパッチがそのように失敗するとは全く思いませんでした。

すぐに、これはおそらく他のソフトウェアにも影響を与えるであろう、より深い問題に遭遇したことが明らかになりました。幸いなことに、Stuartは彼の多大なスキルを使って、問題をより根本的に解決し始めました。私はプライベートメールでいくつかのパッチをテストし、追加の提案をしましたが、この時点で、より知識のある人が担当してくれたことを嬉しく思いました！最終的な修正が、OpenBSDのダイナミックリンカーにRTLD_NOLOADサポートを追加することだったとさらに嬉しく思いました。なぜなら、それによってmoldをOpenBSDでビルドできるようにもなったからです！

gimpのクラッシュ

私は平たい足のヒキガエル並みの芸術的スキルしかありませんが、時々ビットマップ画像を編集する必要があります。その必要があるときは、GIMPを使用します。ほとんどの場合、スケーリング、クロッピング、そして（冒険心を感じているなら）基本的な色補正のような簡単なことに使用します。過去にはGIMPの使用中にセグメンテーション違反を経験しましたが、それはまれでした。過去数週間のどこかの時点で、それらは非常に頻繁になりました。最初は、neomuttからGIMPを起動することが多いからだと思っていましたが、ターミナルから直接起動しても、定期的なクラッシュが見られました。

写真の明るさを変更しているときにこれが数回発生した後、少なくとも他の誰かが同じ問題を見ているかどうかを確認することにしました。これらのクラッシュは直接GIMPのせいではなく、おそらくOpenBSD関連だろうと疑っていました。残念ながら、簡単なトリガーを見つけることができませんでした。例えば、ファイルを保存するときにクラッシュすることがありましたが、同じ手順を踏んでも常にそうではありませんでした。そのため、迅速かつ簡単なことをしました。GIMPをgdbで実行し、クラッシュするまで待ってからバックトレースを印刷しました。そこから、OpenBSDのポートメーリングリストに簡単なバグレポートを投稿しました。

私はGIMPのヘビーユーザーではありませんが、過去数週間、使用するたびに定期的にセグメンテーション違反が発生していることに気づきました（例：保存時、色調整時）。今朝、私のamd64スナップショット+パッケージを更新した後も問題が発生しています。以下は、問題がbablにある可能性を示唆するgithub¹¹からのバックトレースの例です。他の誰かがこの問題を目撃したか、あるいは何が原因であるか（または何が原因であったか）についてのアイデアを持っているか疑問に思いますか？
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 523403]
0x00000445260f63ec in rgbaf_to_Labaf_sse2 () 
   from /usr/local/lib/babl-0.1/x86-64-v3-CIE.so
(gdb) bt
#0  0x00000445260f63ec in rgbaf_to_Labaf_sse2 () 
   from /usr/local/lib/babl-0.1/x86-64-v3-CIE.so
#1  0x00000444488ef45c in babl_fish_lut_process_maybe () 
   from /usr/local/lib/libbabl-0.1.so.1.8
#2  0x00000444488eddab in babl_fish_path_process () 
   from /usr/local/lib/libbabl-0.1.so.1.8
#3  0x00000444488ee04c in babl_process_rows () 
   from /usr/local/lib/libbabl-0.1.so.1.8
#4  0x0000044526c67852 in gegl_buffer_iterate_read_simple () 
   from /usr/local/lib/libgegl-0.4.so.0.5
...

それは素晴らしいバグレポートではありませんが、私がこれまでに提出した中で最悪のものでもありません。他の人々が同様の問題を目撃しており、それが、何が起こっているのかを特定するのに役立つかもしれないと期待しました。他の誰も返信しませんでした。おそらく、問題は私だけに影響するからか、あるいは私のように、ほとんどの人が問題に軽度にしかイライラしなかったからかもしれません。この時点で、私は損失を切り上げて先に進むことにしました。一週間ほど後にGIMPを再度試したところ、問題は消えたように見えましたが、さらに一週間後には再び現れたように見えました。なぜ？全くわかりません！

neovim-qt

バグレポートが解決に数週間、あるいはそれ以上かかることは珍しくありません。7月初旬に、neovimに対してShift-Backspaceが機能しなくなったというバグレポートを提出しました。すぐに、neovimではなくneovim-qtの挙動が変わったことが判明しました（バグレポートは一時的にneovim-qtのリポジトリに移り、その後neovimのリポジトリに戻りました）。

話を短くするために、一部のユーザーはneovimのターミナルモードで誤ってShift-Backspaceを押した場合に変な文字が挿入されるのを好まないため、neovim-qtはShift-Backspaceを完全に無視するようになりました。しかし、私のような一部の変わった人々は、通常の編集モードでShift-Backspaceを使用します¹²。

したがって、neovim-qtの作者は、2つの明らかに互換性のないユーザーの要望の間に挟まれてしまいました。おそらく実用的ではない解決策をいくつか提案した後、このブログ記事に関連する週に、私はついに可能な解決策を思いつきました。これは、neovim-qtがデフォルトでShift-Backspaceをno-opにバインドできるというもので、すべての人を満足させるかもしれません。それは妥協ですが、私がこれまでに提案した中で最悪の妥協ではありません！

私の提案は、最初のレポートから1ヶ月以上経過してから来たことに注意してください。これはneovim-qtまたはneovimの作者に対する非難ではありません。これは、関係者全員が簡単な修正方法を思いつかず、物事がしばらくの間くすぶり続けるような難しいバグの例です。

終わりに

私はかなりの量のオープンソースソフトウェアを開発し、保守しています。バグレポートを自尊心を傷つけるものと見なすことは可能です。それぞれが、私が正しいソフトウェアを作成できないことを思い出させます。率直に言って、私はその点での自分の限界にかなり折り合いをつけており、今では新しいバグレポートが来ると、その時間とコード品質への影響だけを考えます。少なくとも、レポートが正しいかどうかを理解する必要があります。もしそれが正しければ、それを修正したいかどうかを決定する必要があります。そして、もしそれを修正することに決めたら、それに必要なだけ時間を費やし、他のものを壊さないように最善を尽くす必要があります。

したがって、バグレポートを作成する際には、開発者に共感的であることを目指しています。たとえ彼らが私のレポートを30秒で却下したとしても、私は彼らの時間を30秒奪ったことになります。そして、多くの開発者はバグを理解し修正するために何時間も費やすでしょう。バグレポートを作成する唯一の倫理的なことは、報告する前にバグを完全に修正することだと考えるかもしれません。しかし、私が十分に熟練していたとしても、そんな時間はないと思います！

したがって、バグを報告する際には興味深い緊張関係があります。私が費やす努力が大きいほど、バグが解決される可能性は高くなりますが、すべてのバグに最大限の努力を費やすことはできません。代わりに、遭遇したバグをトリアージしてから、報告するかどうか、そしてどの程度まで報告するかを決定する必要があります。私が考慮する主な要因は、バグの深刻さ、私に影響する頻度、それを合理的に説明できる能力、そしてそれを修正できると思うかどうかです。

プログラムへの習熟度は重要な要素です。私にとって新しいプログラムの場合、バグに遭遇するために行ったことを説明するのに苦労するかもしれません。もし修正を試みるべきだと思うなら、プログラムの内部構造への習熟度が鍵となります。専門家からは程遠いですが、OpenBSDカーネルコードの一部を、特定の軽微なハードウェアバグを修正するチャンスがあると思うほどよく知っています。しかし、Thunderbirdのソースコードを見たことは一度もなく、どこから始めればよいかもわかりません！

コミュニティ内での習熟度と、コミュニティ自体への習熟度も違いを生みます。私は間違いなく周辺にいますが、20年以上OpenBSDのメーリングリストで半アクティブに活動してきました。さまざまな種類のバグをどこに報告すべきかを知っているだけでなく、そのコミュニティの期待をよく理解しています。また、一部の開発者が私の名前を覚えていることに頼ることもできます。それが、誰かが私の提出したバグの修正を提案したときに、私が常にテストしてフィードバックするようにしている理由の1つです。たとえ人々が私を愚かだと考えていても、少なくとも彼らが私を良心的な愚か者だと考えてくれるなら、それは害にはなりません。対照的に、Thunderbirdのバグを報告する場所¹³を見つけるのに20分かかりました。そして、それがどのように受け取られるか全くわかりませんでした。バグが真剣に受け止められたのは喜ばしいことでした。

しばしば忘れられたり、義務の提案のために嫌われたりしますが、開発者の応答性は、人々がバグを報告する頻度と質に大きく影響する要因です。率直に言って、質の高いバグレポートを作成するのに時間を費やしても、何も返ってこないほどモチベーションが低下することはほとんどありません。それは私がさらにバグを報告する可能性を低くするだけでなく、より積極的にメンテナンスされている代替手段に移行する可能性を高めます。疑いの余地がないように、オープンソース開発者は私や他の誰にも何も負っていないことを改めて強調したいと思います。しかし、ユーザーベースがもっと大きければよいと思っている開発者に数多く出会いましたが、質の高いバグレポートに数ヶ月かけて返信したり、全く返信しなかったりします。その2つの要因の関連性を示唆することを好まないかもしれませんが、それは私には避けられないように思えます。

上記の要因のいくつかは、この記事のバグレポート全体に見られます¹⁴。例えば、GIMPをあまり使わないので、バグの根本原因を見つけるのに多くの時間を費やす気にはなりませんでした。対照的に、ラップトップの右マウスボタンを使えるようになりたかったので、修正を見つけるのに多くの時間を費やすことを厭いませんでした。

時間をかけて、バグレポートを次のカテゴリに分けました。「最高」から「最低」までです。

テストケースと完全な修正。
テストケースと部分的な修正。
テストケースのみ。
バグを引き起こす方法の部分的な説明。
バグの影響の説明。
有用な詳細なし（本質的に「動作しない」だけで、それ以上はない）。

私は#1のバグレポートを「決定版」と見なします。#2と#3は、開発者が何が起こったのか、そして修正がどのように開発される可能性があるのかを理解するのに十分なことが多いです。#4と#5はどちらにもなり得ます。そして#6は無用よりも悪い。私の感覚では、#6のレポートは、平均的なユーザーが経験が少なくなるにつれて、より人気のあるプロジェクトで不均衡に一般的になるようです。

一般的に、私は少なくともカテゴリ#3以上のバグレポートを提出したいと考えていますが、多くの場合、管理できるのは#4または#5だけです（例：Frameworkのビデオ表示問題）。そして時には、私ができるのは#5だけです（例：GIMPバグ）。もちろん、私のレポートの質が低いほど、他の開発者が気にする可能性、または彼らが私のレポートで何かをできる可能性は低くなります。これは彼らに対する非難ではありません。私はオープンソースソフトウェアにお金を払っておらず、見返りを期待していません。

この記事を書くことから気づいたことの1つは、私の最初のレポートのカテゴリが低いほど、それが正しい可能性は低くなるということです。ThunderbirdのiCalendarバグの私の最初のレポートは、表向きは#3でしたが、間違った原因を特定したため、議論の余地があることに#4でした。私が間違いに気づいた後になって初めて、それは本当に#3になりました。最初にレポートするのが早すぎたのでしょうか？おそらく。しかし、バグを報告するのが遅すぎると、重要な詳細を忘れがちになり、時には何も報告する意欲を失ってしまいます。正しいバランスがどこにあるのか、よくわかりません。

この記事から明らかにわかることの1つは、たとえ質の高いバグレポートであっても、最初のレポートだけではめったに解決しないということです。開発者が状況を理解しようとし、報告者が原因を絞り込んだり、可能な修正を試したりするのを助けるために、報告者と開発者の間の継続的な対話がしばしばあります。頻繁に、その対話は数日間続き、時には数週間続きます。バグレポートを再活性化するためにいつ人に ping するかを知ることは、本当のスキルであり、私が常に正しくできることではありません！

最後に、この記事が示唆するかもしれないことにもかかわらず、私は現代のソフトウェアが驚くべき高い品質レベルを達成したと固く信じています。もし私がDan Luuの2014年のOne Week of Bugs実験を今再現しようとしたら、より少ないバグ、そしてより悪いバグに遭遇するだろうと推測します。より良い開発プロセス（例：継続的インテグレーション、より広範なテスト）がこの改善の要因の1つです。しかし、もう1つの要因は、人々が時間をかけてバグを報告する努力の累積効果です。バグ報告に費やした時間は非常に価値のある時間だったと考えています！

謝辞: Edd Barrett、Dan Luu、Davin McCall、およびHillel Wayneにコメントを感謝します。

新しい記事 2022-08-31 08:00 古い記事

新しいブログ記事の更新情報をご希望の場合は、MastodonまたはTwitterでフォローしてください。またはRSSフィードを購読するか、メール更新を購読してください。

注釈

この記事を書いている間、「開発者」または「メンテナー」という言葉を使うか迷いました。ある程度、これらの用語は文脈上同義ですが、完全ではありません。私は一部のソフトウェアを積極的に「開発」しますが、他のソフトウェアは最小限しか「メンテナンス」しません。全体として、より多くの人が「開発者」だと感じるだろうと思いましたが、もしあなたが後者の言葉で記事を読むことを好むなら、ご自由にそうしてください！

☒

これを裏付ける確かなデータはありませんが、私の直感では、長期間続くほとんどのバグは、考え抜かれていない仕様を正しく実装した結果であるということです。ほとんどの場合、仕様は不完全だと思いますが、一部の場合は単に間違っています。それは批判ではありません。ほとんどのソフトウェアは必然的にカスタムメイドであり、実際に手元に届くまで、それが本当に何をすべきかを理解するのに苦労します。

☒

順に：T40（まとも）、T43（良い）、T410s（ひどい）、X220（素晴らしい）、X1 Carbon第3世代（良い）、そして最後にX1 Carbon第6世代（非常に良い）。ひどい画面、ひどいバッテリー寿命、そして重すぎたT410sを除いて、私はThinkpadで非常に良い経験をしました。

☒

私は、a) neovimの言語サーバーサポートが非常に優れていること、b) clangdをインストールしていたことに非常に幸運でした。そのため、OpenBSDカーネルのこの非常に馴染みのない部分をナビゲートするのは、そうでなかった場合よりもはるかに速かったです。おそらく数年前に諦めていたでしょう。

☒

あまり使わないので、トラックパッドがクリックパッドとして認識されなかったときに、中央のマウスボタンも機能しなくなったことには気づきませんでした。

☒

korganizerを使用した結果、私のカレンダーはまだ~/.korganizer.icsです！

☒

korganizerを使用した結果、私のカレンダーはまだ~/.korganizer.icsです！

Thunderbirdがこの行を嫌う正確な理由は私には不明ですが、このプロパティの仕様を見ると、ここでのタイムゾーンの欠如が実際の問題であるのではないかと疑われます。しかし、タイムゾーンの欠落について二度目の狼少年にはなりません！

☒

すぐに、レポートを更新してくれたことに対して感謝する、非常に丁寧なプライベートメールをThunderbird開発者から受け取りました！

☒

すぐに、レポートを更新してくれたことに対して感謝する、非常に丁寧なプライベートメールをThunderbird開発者から受け取りました！

これを書いているうちに、Pythonライブラリにもバグを報告すべきだったことに気づきました！

☒

これを書いているうちに、Pythonライブラリにもバグを報告すべきだったことに気づきました！

バイナリ「パッケージ」は「ports」と呼ばれる説明から作成されます。

☒

バイナリ「パッケージ」は「ports」と呼ばれる説明から作成されます。

明らかに「gdb」と書くつもりでしたが、GitHubのプルリクエストをレビューするのに人生の半分を費やしているので、おそらくタイプしているときにそれが頭にあったのでしょう！

☒

私にとっては「前の単語を削除する」という意味です。これは25年前にStrongEDから覚えたと思われるキーボードショートカットですが、確信はありません。

☒

GitHubとイシュートラッキングの広範な使用により、一般的なオープンソースソフトウェアのバグレポートをどこに提出すべきかを理解することが、一般的にずっと容易になりました。これはGitHubのイシュートラッキングが完璧であるという意味ではありません。実際、多くの欠点や制限がありますが、少なくとも何が期待できるかはわかっています。

☒

この記事では、1週間で作成した4つ（または数え方によっては5つ）の新しいバグレポートを詳しく説明しました。また、関与していた追加の進行中のバグレポートも含まれています。その週に私のソフトウェアに対して人々が作成したバグレポートは含めていません。この記事はすでに十分に長いと思います！

☒