2005年4月 6日
バグ
カテゴリー:
[プログラミング]
ここしばらく悩まされていたバグが，実は，JRE自体のバグだったことが分かりました．
動かし続けていると，ファイルディスクリプタを食いつぶして，"Too many open files" になって，ファイルに抽象化されているあらゆるものが開けなくなってしまうという問題だったのですが，コードをどんなに修正しても直りませんでした．
結局，JRE自体にバグがあったわけです．SocketChennel を使ってソケットを作って，なおかつ，setSoTimeout() でタイムアウトを設定すると，close が効かなくなるバグでした．そのため，リソースリークしてしまいます．
例外も何もいっさいでないので，原因がさっぱり分かりませんでした．
Bug ID: 4726957 (so) Socket.close fails if timeout set on Socket created from SocketChannel
Bug ID: 4724030 (so) Async close of socket stream fails when timeout specified
使っているのは，1.4.2 系ですが，このバグは，まだ，fixされていないようです．ずいぶん昔からあるバグのようですが．．．
JavaのNIO(new I/O) 関係には，未修正のバグが他にもあるようです．
Bug ID: 4720952 (so) SocketChannel.socket().getInetAddress() returns null after close
最近，new I/O の機能を使っていろいろ作っているので，ちょっと気を付けないとまずいです（＾＾；
しかし，Java の new I/O にこんなに問題があるなんて，ちょっと思いませんでした．
通常，バグが出たときは自分のコードを疑うものです．よくテストされたコンポーネントを疑うより，書いたばかりの自分が書いたコードを疑う方が理にかなっています．ただ，ごらんの通り，たまにこれは裏切られるわけです．
もちろん，コードが手元にないので，一定上の検証ができないので，自分のコードを調べるしかないというのも理由です．
今回のように，長時間動かしてリソースを食いつぶさないと発覚しない，リソースリークがらみのバグだと，テストコードを書いても，なかなか再現しなかったりします．そもそも，何が原因なのか調べるだけで，一苦労です．
ソフトウェア部品の再利用は，これからも増えていくでしょうが，その一方でこの手の問題は増えていくでしょうね．バグの原因が見つからないことや，コンポーネント側に問題があることが分かるまで時間がかかることも，もちろん問題ですが，それよりも，バグが回避できなかった場合には，さらに致命的な問題となります．
研究で，ソフトウェア・コンポーネントをテーマにしているので，このあたりは，研究的にも興味あるところです．もっとも，こういう問題に技術的対処がどこまで有効かは分かりませんが．
そういえば，Javaをオープンソース化するべきか，するべきでないかという話題が，しばらく前からよく出ていますが，Sun Microsystems は Java の分裂を危惧して，一貫してオープンソースにはしないという態度です．
でも，いつまでも直らないバグがあったりすると，自分で直したい人もいるでしょうねえ．もっとも，オープンソース化してバグが減るかは分かりませんが．．．．
投稿者 shingo : 2005年4月 6日 00:50
トラックバック
このエントリーのトラックバックURL:
http://isolinear.info/cgi-bin/mt/mt-tb.cgi/73