IME の基本性能を向上させる手法 – Windows エラー報告

  こんにちは。   今回は、IME チームで行っているソフトウェアの基本性能を向上させるための手法、Windows エラー報告、を紹介したいと思います。   IME チームは、物理 PC と仮想 PC を組み合わせて100台規模の PC 上で様々なテストを実施し、出荷に向けて様々な問題に取り組んでいます。Beta 版ができた時には、社内、社外の方々のご協力を得て、数百名規模のユーザーの方々からフィードバックをいただき製品品質向上に取り組んでいます。クラッシュに関する問題も報告されてくることがあり、そのほとんどは Windows エラー報告 (WER – Windows Error Reporting) を経由して IME チームに直接報告されてきます。   Beta 版も含めて、出荷する前に様々なクラッシュの問題に取り組んではいますが、実際、IME チーム内ではなかなか見つけられない問題は少なからず存在し、ユーザー様からのエラー報告によって初めて認識されるというものもあります。これは、ユーザー様の様々な環境や、そこで行われる多様な操作の組み合わせと比較すると、IME チーム内でできるテストは限定的であるといわざるを得ない状況もその一因にあるようです。そういう意味でも、Beta 版を使っていただき、問題点を報告していただけるユーザー様には大変感謝しています。   そのように貴重なフィードバックである Windows エラー報告ではありますが、そこで寄せられるクラッシュの問題に取り組むには様々な困難があります。送られてきた報告の中には、もはや何が問題であったのかが分からなくなってしまっているものもあり、様々な手法を用いて分析し問題点をあぶりだす必要があります。   その1つは、ユーザー様がクラッシュに遭遇する直前に行っていた操作の仮説を作ることです。この作業は、ほとんどの場合、コールスタックを解析することで行われます。そして、この仮説からクラッシュを再現させることができる、、、ということは、残念ながら過去にそのような例はありません。したがって、この仮説を踏まえつつ、さらなる解析が必要になります。   もう1つ大事な作業は、クラッシュの定量的解析を行うことです。同じような問題はどの程度発生しているのか、そのクラッシュは x86、x64 の両方で発生しているのか、どの OS でどの程度発生しているのか、影響を受けているアプリケーションにはどのようなものがあるのか、などエラー報告で得られる限られた情報の中からそのような解析を行います。そうすることで、多くのユーザー様が遭遇している問題、特定のアプリケーションのメモリ破壊ではない問題、特定環境下でのメモリ (RAM) エラーではない問題、などふるいにかけることができ、問題の修正にこぎつけることができます。   IME チームは、このように IME を使ってくださる皆様に支えられながら、チーム一丸となり日々精進しています。   松原 司牧  

0

IME の基本性能を向上させる手法 – RADAR

こんにちは。   今回は、IME チームで行っているソフトウェアの基本性能を向上させるための手法、RADAR、を紹介したいと思います。   以前、IME は母体となるアプリケーションと共に動作しているというお話をしましたが、そのような性質ゆえに重要な問題となるものにメモリ リークがあります。たとえば、Notepad と共に動作している IME がメモリ リークを起こしたとしてもさほど気にする人はいないかもしれません。Notepad を終了させれば、そのメモリ リークは解消されるからです。しかし、Explorer と共に動作している IME がメモリ リークを起こしていたとしましょう。いつしかシステムは重たくなり、リブートしない限り使いものにならない状況になってしまうことでしょう。そしてそれは永遠に繰り返されることになります。つまり、単体で動作しているアプリケーションではさほど気にならないメモリ リークであっても、IME にとっては重要度が高くなるといえると思います。   しかし、メモリの使用量が増えるからと言って、即座にメモリ リークが発生したと言うことはできません。コードの中で行われているデータ キャッシュが適切に動作しているために一時的なメモリ使用量が増えているだけの場合もあるでしょう。また、メモリ リークによってメモリの使用量が増えていたとしても、コードの中からその場所を特定するのは困難な作業になります。   RADAR は、メモリ リークを検出する Windows の機能です。IME チームは、この RADAR を使い、メモリ リークに分類される問題の中の参照不可能なメモリを検出し、IME の基本性能の向上を行っています。   メモリ リークには、その種類によっていくつかに分類されます。メモリは、malloc() や new などにより確保することができ、アドレスを格納した変数を介して使用することができます。確保したメモリが解放される前に、そのアドレスを格納している変数がなくなってしまうと、コードの中ではそのメモリへアクセスする手段を失います。これにより、参照不可能なメモリが発生します。C# などのマネージ コードであれば、ガーベージコレクションという機能により解放されるメモリです。ネイティブ コードで記述されている IME では、適切なメモリの確保、解放が必要になります。   残念ながらここで紹介した RADAR は、Microsoft 社外の方々には、まだその本来の機能を提供できていないようです。Windows 用デバッグ ツール に含まれている UMDH を使うことで似たようなことは行うことができると思いますので参考になれば幸いです。   RADAR…

0

IME の基本性能を向上させる手法 – Application Verifier

こんにちは。   今回は、IMEチームで行っているソフトウェアの基本性能を向上させるための手法、Application Verifier、を紹介したいと思います。   IME が他のソフトウエアと大きく違うところの1つに、IME は単体で動作するというよりは、母体となるアプリケーションと一緒に動作するところにあります。変換結果などをアプリケーションに渡したりするためです。この性質ゆえに、IME のモジュールの一部は、アプリケーション (プロセス) 内で動作しています。これらのモジュールの動作が不安定であるとアプリケーションに影響が出てしまうこともあり、特に、クラッシュのような問題は避けなければなりません。   クラッシュの問題に対応するという作業は、意外に困難な作業です。たとえば、コード内で間違ったこと (バッファー オーバーランなど) が起こったとしても、その影響が軽微であればアプリケーションは何事もなく動いてしまうものです。そして本当にどうしようもなくなったときに初めてクラッシュするため、クラッシュした時点では何が問題なのかもはやわからない状況になっているということはよくあるケースです。また、IME の一部のモジュールのようにアプリケーションと一緒に動作していると、クラッシュした時にはIME の問題なのか、アプリケーションの問題なのか、それを適切に切り分ける作業が必要になるため、容易には結果を得ることができません。たとえば、アプリケーション側のメモリの不正アクセスにより、IME 側のメモリが破壊されるという可能性もあります。   実際、IME 2010 の開発初期の頃には、多くのクラッシュに遭遇したものです。一昔前であれば、クラッシュしてしまうとそこで作業が中断されてしまうものでした。また、もう一度再現させようと思っても再現させることができず、闇に葬られてしまうような問題もあったかもしれません。しかし、今では、100 台規模の PC 上で実行されている自動化されたテストプロセス内で発生した1つ1つのクラッシュであっても、適切にとらえ対応することが可能になりました。   Microsoft が Application Compatibility Toolkit の一部として提供している Application Verifier (AppVerifier)  は、そのような困難な問題を解決する手段を提供してくれます。Application Verifier は、コード内で間違ったことが行われたその瞬間にアプリケーションを止めてくれます。その状態を解析することで、原因となったコードを適切に把握することが可能になります。検出できるコード内の誤りも多岐にわたるため、IME に限らず、アプリケーション開発の大きな助けになります。   さらに、Windows 用デバッグ ツールを併用することで、先に挙げたような問題の切り分け、問題となるコードの抽出など、昔は高い技術力を要し、数日~数週間もかかる作業だったものを、瞬時に、かつ、高い精度で自動的に行うことができます。   IME チームは、このような Microsoft 社内で開発されている技術の進歩に支えられながら、基本性能の高い IME の開発を進めています。   松原 司牧

0