2011年05月06日

NetBSD 4_STABLEのバグ

この連休は3日に職場のサーバーのディスク交換、普段止めるのが難しいメールサーバーやってるマシンのディスクの交換をした。元々NetBSDのRAIDframeを使用してRAID1の構成をしていたうちの1台なので、運用上の障害は起きていなかった。こちらは問題なく完了、続けてしばらくできていなかったパッケージの更新も行う。
一方、ついでに某ユーザーグループのサーバーの更新も行ったところ、spamassassinのspamdが動かない。何とperlが起動途中でcore dumpする、そう言えばmakefmlがcore dumpするので、p5-NetAddr-IP辺りのバージョンを上げるのを止めたのだった。
職場のサーバーではcore dumpするようなものは動かしていなかったので特定のマシンに依存しているかと思いきや、再現できることが帰宅後に判明した。結局、一時的にspamdは止めて結果としてspamがいっぱいやってくる。(自分宛は自宅のメールサーバーで、改めてフィルタリングされていた。)
そして今日になって、とあるユーザーグループのサーバーについてはあきらめてNetBSD 5_STABLEに更新。カーネルだけのときは問題は解決せず、ユーザーランドを更新したところ問題は嘘のように解消してしまった。
これは!  と思い、
  1. 改めて手元のnetbsd-4なツリーの大丈夫だった年明け早々のバージョンと現在のコードを比較。
  2. ユーザーランドのめぼしいところで変わっているのはbindの更新(9.4-ESV-R4に更新)くらい。
  3. よーく見るとlibc以下に変更されたファイルがチラホラ。
ということで、__RCSID以外が変更されている、
lib/libc/resolv/res_init.c
lib/libc/resolv/res_mkquery.c
lib/libc/resolv/res_query.c
lib/libc/resolv/res_send.c
を戻してみた。すると、問題は解消する。1つずつ(res_mkquery.cとres_query.cは別々に更新できないので一緒に)後ろから戻していくと、res_init.cで見事に落ちる様になった。さらに落ちてる関数もわかっていたので、どの辺りまで進んでいるかはprintf(3)的方法で確認。
落ちてる部分がはっきりしたので、コードを改めて眺めるとあー、怪しい。NetBSD currentでは9.8.0rc1(何て中途半端なバージョン)がインポートされてるので比較してみると、やはりそういうことかと答が出た。バグな部分を踏んだ結果っとして、無関係なところをfree(3)するなどしてメモリーをぶっ壊して落ちている感じである。
といった問題をBIND 9.4-ESV-R4がEOLとなる今月に見つけてしまうのは何となく感慨深いような。って、そう言えば今日のBIND 9.8.0の脆弱性はNetBSD currentは影響あるんではないだろか!?
ともかく3, 4時間程度で解決できて良かった、まだNetBSD 4_STABLEには頑張って貰わないと。
posted by Takahiro Kambe at 23:49| 京都 ☁| Comment(0) | TrackBack(0) | NetBSD | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。