結城です。

先日、Thunderbirdに提供したパッチが開発版に取り込まれ、その後Thundebrird 78.8.0にも取り込まれる運びとなりました。

このフィードバックは、法人向け技術サポート業務で受けたお問い合わせが起点となって行った物でした。この記事では、お問い合わせからフィードバックまでの経緯を簡単に振り返ってみたいと思います。

お問い合わせと状況の把握

当初頂いていたお問い合わせは、「Thunderbird 78.6.0でのアドレス帳のインポート時に必ず以下のようなエラーメッセージが表示される。Thunderbird 68ではこのエラーは出ていなかったはず」というものでした。

テキストファイル(LDIF,.tab,.csv .txt)からアドレスをインポート中にエラーが発生しました。
アドレス帳 XXXXX のインポート中にエラーが発生しました。インポートされていないアドレスがあるかもしれません。

現象の再現確認用のCSVファイル（およびその作成手順）も同時にご提供頂けたため、こちらの環境でも検証した所、確かに以下の状況であることを確認できました。

• Thunderbird 68では現象が再現しない。
• Thunderbird 78.6.0では現象が再現する。
• 現象発生時も、インポート自体は期待通りに完了している（インポート結果に特に抜けなどは無い）ように見える。

お客さまは「とりあえず使えるようだが、不安が残っている」状況です。何が起こっているか分からないということは、もしかしたらアドレス情報が誤ってインポートされているかもしれず、ともすれば、使っているうちに誤送信による情報漏洩が発生する危険性が無いとも言い切れません。

エラー発生時の状況の把握

ということで、技術サポートとしてはその不安を払拭するための情報を提供する必要があります。具体的には、エラー発生時に実際には何が起こっているのか、もしインポートできていない情報や誤ってインポートされている情報があるのであれば、それは何なのか、ということを明らかにしないといけません。実際には何も問題が起こっていないのであれば、安心してエラーを無視できますし、何か起こっているのであれば、それに対する回避策を組み合わせた運用を取ることもできます。

今回のようにエラーメッセージが表示されるケースでは、メッセージの定義を手がかりに調査を始めるのが基本です。

今回は、Mozilla関係プロダクトのソースコードのオンライン検索システムであるsearchfox.orgを使い、ローカライズ用リソースのリポジトリに対して、「のインポート中にエラーが発生しました。インポートされていないアドレスがあるかもしれません。」というメッセージで検索を実行してみました。すると、textImportMsgs.propertiesというファイルの中でメッセージが定義されていることが分かりました。

次に、このメッセージに対応するキーで（今回はエラーコードがキーとなっていたため、エラーコードの定数名でも）Thunderbird 78本体のソースコードを対象に検索したところ、nsTextImport.cppというファイルの中で確かにこのエラーコードが使われている箇所が2箇所ある（1, 2）と分かりました。

ソースコード上のエラーの出所を特定できたら、次は、このエラーが発生したときの状況を追います。

このファイルはC++のソースコードですが、FirefoxやThunderbirdでは、C++の実装ではLazyLogModuleという仕組みでログを出力するようになっている場合があります。このファイルも、想定外の事態が発生した際にはImportというモジュール名でログを出力するようになっており、エラーを示すステータスコードをreturnする直前で都度ログを出力している様子でした。

LazyLogModuleによるログは、環境変数を使って以下の要領でThunderbirdを起動すると、指定の場所に出力できます。

set MOZ_LOG=Import:5,sync
set MOZ_LOG_FILE=%temp%\import.log
"C:\Program Files\Mozilla Thunderbird Beta\thunderbird.exe"

そうして得られたエラー発生時のログは、以下のような内容でした。

...
[(null) 14484: Main Thread]: D/Import In GetAddressBook
[(null) 14484: Main Thread]: D/Import In Begin ImportAddressThread
[(null) 14484: Main Thread]: D/Import *** Text address import done

ところが、実はこのログには、ソースコード上で記述されていたエラー情報のログメッセージが一切出力されていません。In Begin ImportAddressThreadの行がインポート処理を開始した時点、*** Text address import doneの行がインポート処理を完了した時点のログメッセージなのですが、その間に何もログが出力されていない状況です。

そこで、エラーのログが出力されないケースでエラーのステータスコードがreturnされるケースがないか、処理の流れを辿ってみたところ、すべてのインポート処理が完了して正常終了していると思われる場面で、何故か「成功」を示すステータスコードではなく「未実装」を示すステータスコードがreturnされていると分かりました。また、この行の出所をannotated diffから調べてみたところ、Thunderbird 71で行われたアドレス帳に関する実装の大規模な書き換えの変更の過程で導入された様子でした。これは、「特に何も問題が起こっていないのにエラーが報告される」「Thunderbird 68では現象が発生せず、Thunderbird 78では現象が発生する」という状況と一致しています。

Mozilla関係のプロジェクトにおいては多くの場合、大規模な書き換えでは、メソッドが返すステータスコードは「未実装」の状態から作業を始め、一通りの作業が完了した時点で「成功」を返すコードになる、という経過を辿ります。それを踏まえると、この行は何らかの理由でステータスコードを「成功」に書き換え忘れたままになってしまっている可能性が考えられました。

以上の調査結果に基づいて、お客さまには「こういう経緯でエラーが表示されている状況のため、実際には何も問題は起こっておらず、エラーを無視して問題ない」旨をお知らせしました。

開発元へのフィードバック

当社では、OSSの利用の過程で見つけた不具合は可能な限りアップストリームにフィードバックする方針を取っています。これは、単に倫理的な「べき」論だけではなく、フィードバックを通じてソフトウェアの品質が向上すると、ソフトウェアの魅力が増して利用者が増え、結果的に当社のビジネスにつながると期待できるから、という実利的な理由もあります。

今回も、ここまでで調べた情報を添えて、Mozillaが運用するBugzillaに以下の報告を行いました。元々頂いていたお問い合わせの時点で、発生条件や再現手順がかなりの部分まで明確化されていたため、報告は非常にスムーズに行えました。

• 1685048 - Importing address book from a CSV file always reports an error even if successfully imported

報告にあたって、「未実装」のステータスコードが返されているのはThunderbird 78での後退バグなのではないか？という推測を記載したところ、開発者から「確かにそのようで、成功のステータスコードを返してよい場面だ」というコメントを得られました。また、併せて、そのような変更を行うパッチの作成を依頼されました。

OSSの実装に対する変更を提案する際は、問題を修正する変更と、その変更が期待通りに作用していること・望まない副作用が発生していないことを確かめる自動テストもセットで提供するのが定番です。今回は、問題そのものの修正の仕方はもう分かっていますが、修正結果をどうやってテストをするかは、これから考えなくてはいけません。

そこで、参考にするためにアドレス帳のインポート処理に関する既存の自動テストを調査したところ、既存の自動テストでは、インポート完了後のエラーコードの確認自体がそもそも行われていなかったと分かりました。こうなると話は単純で、既存のテストに「インポート処理において何もエラーが発生していなかったこと」を確かめるアサーションを追加するだけで、要件を満たせると期待できます。

以上を踏まえ、当該メソッドで成功のステータスコードを返すようにしつつ、自動テストも修正する変更を行い、ローカル環境でテストを実行して、既存のテストがすべて成功していることを確認した上で、変更内容を提出しました。その結果、パッチは無事Thunderbird開発版¹にマージされ、追って、開発チームの判断で現行バージョンのマイナーアップデートにも変更が反映されることになりました。

まとめ

以上、当社の法人向け技術サポート業務の中で行った、障害の原因調査とフィードバックの事例をご紹介しました。

ソフトウェアを業務や普段の生活で使用していると、不可解な挙動に遭遇する場合が度々あります。単純に使い方の問題であることもありますが、深掘りして調べてみると、今回のようにソフトウェア側の不備が見つかることも少なくないです。そのようなときは、そのソフトウェアがOSSなのであれば、開発プロジェクトにフィードバックすることを是非検討してみてください。

1人でフィードバックすることに不安があるけれども、周囲に相談できる相手がいない、という場合は、OSSに関わる人を継続的に増やす取り組みのOSS Gateのワークショップやチャット（Gitter）でサポーターに相談してみたり、ワークショップでよく行っているアドバイスの内容をまとめた本を読んでみたりするとよいかもしれません。

また、当社では、「遭遇したOSSの不具合を開発元にフィードバックする」文化を社内に根付かせることを意図した研修としての、社内でのOSS Gateワークショップの実施も承っています。OSSにフィードバックする文化を新規メンバーへどのように伝達すればよいか、お悩みのシニアエンジニアの方がいらっしゃいましたら、メールフォームよりお問い合わせください。

ツイートする

フォローする