外部のライブラリーが絡むバグは滅茶苦茶厄介

注意: この記事は1年以上前に掲載されたものです。情報が古い場合がありますのでお気を付け下さい。

これまで開発に携わってきた中で、個人的に最も厄介なバグだと考えているのが、外部のライブラリーが絡んでいるバグであると考えている。特にそのライブラリーがソースコード形式ではなく、バイナリーのみだった場合、非常に厄介なものとなってしまう。

通常の場合、自分たちで開発しているコードだけに起因するバグである場合、基本的には切り分けて原因を探り、修正を加えれば良い。特に大きなプロジェクトなどでもオブジェクト指向の考え方を徹底して、クラスベース、あるいはインスタンスベースの双方においてもパーツの組み合わせで開発している場合は、特に切り分けがしやすくなるので、修正も楽になるだろう。

外部のライブラリーに起因するバグであっても、ソースコード形式のものについては、そのライブラリーの実装の仕方やライセンスなどにもよるが、通常の場合、原因を探って修正を加えることが可能であるため、コードの仕組みがわかってしまえばそれほど苦労せずに修正を加えることは可能である。

しかしながら問題となるのは、外部のライブラリーでも、ソースコードが公開されておらず、バイナリー形式のみで提供されているものの場合である。これについては、デバッグ時に出力されるログや、返ってきた値あるいはアドレスなどからデータを読み出さなければならず、修正も自力では事実上不可能であるため、ライブラリー作成者に報告するほかない ((しかも対応してもらえる確証はない)) 。

上記でも最悪な部類に当たるのは、ライブラリーを無効にしている時は問題ないのに、ライブラリーを使用することによってポインターのアドレスあるいは変数の値が知らないうちに勝手に書き換えられていて、クラッシュを誘発したとか、不可解で怪しい挙動をした時である。これについては本当に修正が困難になる。

これらの多くは、グローバル変数などのように扱える範囲の大きなものになるほど面倒なことになる。特にライブラリー関連については、知らないうちに他のライブラリーあるいはプログラムの変数などをいじるといったようなことは絶対にあってはならないが、そのようなことが起きた時は本当に面倒なことになる。

外部のライブラリーを使う時はちゃんと確認をして使いたいものである。また、外部に提供するためのライブラリーを作る場合は、他のライブラリーに勝手に干渉するような開発の仕方は絶対にしないようにしたいところである ((そのライブラリー自体が他のライブラリーの機能を必要とする「依存」については少々事情が異なるが。一方、他のライブラリーから依存対象となることもあるので、それらに悪影響を及ぼさないようにすることは絶対条件である)) 。

タイトルとURLをコピーしました