カテゴリー: その他

今日は、OSの再インストールをした。どうも、ハードディスクを２つ差すようにしてから、高い負荷がかかると落ちるような気がしている。そんなわけで、要領の大きなハードディスクを一つにして対応することにした。一応、外向けの部分に関しては、作業が完了。あとは、内向けのサービスを復旧していかないとね。

watchmallocが使えなかったので、次の手として、libumemで使い始めてみた。これはこれでおもしろい。メモリリークとメモリ破壊を調べることができる。libumem.soをLD_PRELOADして、gcoreでコアダンプさせる。そして、mdbでデバッグをする。すると、スタック情報と対象のメモリサイズを得ることができる。この情報から、ソースコード中のメモリの確保・解放を調べていけば、メモリリークと破壊されたメモリがわかるというもの。速度的にも問題がないので、結構使える。これを使って調べていこう。

最近、SourceForge.jpのアクセス数とダウンロード数を見ていると、急激に増えている。なぜだろうか？だれがそんなに急激にダウンロードしているのだろうか？SourceForge.jp にはそこまで解析するツールがないだけによく分からん。どうなっているんだろう？そういえば、そろそろ1.4をリリースしようかね。

でかなりはまった。もしかしたら、FedoraでATOKなどのXIMが動かなかったのは、これが原因だったかもしれない。もうすでに、Redhat9にしたのでまた戻してはまると、いやなのでチャレンジするのはやめておこう・・・。原因は分かれば、簡単なことだったんだが、いつも、X をfreetypeじゃなくて、xttで使っていて、これが原因で、BadValueになっていた。うーん、久々にかなりはまった・・・。疲れた・・・。

Solalis には、メモリ破壊などの調査用にwatchmalloc.so.1がある。LD_PRELOADなどで読み込ませておいて、mallocなどを差し替えることになる。っで、早速、使ってみたが、おそい！manページには、WATCHオプションで、10から100倍遅くなると書いてある。RWオプションでは、1000倍。ほんとに、manページ通りだ。っていうか、こんなんじゃ、めちゃくちゃ速いマシンがないと、つかえないじゃん。使えるのは、HelloWorldプログラムぐらいじゃないのかい・・・。そんなわけで、watchmallocによる調査終了。