Template::Plugin::Hatenaがメモリリークしてる件 - Lism.in * blog

FastCGIプロセスがえらくメモリを食ってるのでおかしいなと思ったら、だんだん育ってる。

怪しい部分は最初から察しがついていたので、ところどころコメントアウトしてabで大量のリクエストを送り込んで、メモリ消費量を見るという原始的な方法でチェック。

どうやら、TTのプラグインが犯人らしい。該当アプリで使ってるのはTemplate::Plugin::Hatenaと、それを下敷きに作った指定区間を一行にまとめて出力する自作のフィルタ。

軽くググってみると、こんなエントリを発見。

それでもやっぱりTemplateToolkitがすき - マツモブログ

ドンピシャ。T::P::Hatenaは見事にメモリリークするコードになってるようです。調査方法も僕がやったような適当なのとは大違い。次にやる時はマネさせてもらおう。

今のコード（0.02）は、

sub filter {
    my ($self, $text, $args, $config) = @_;

    if (Text::Hatena->VERSION >= 0.20) {
        Text::Hatena->parse($text)
    } else {
        my $parser = Text::Hatena->new(%$config);
        $parser->parse($text);
        return $parser->html;
    }
}

てな具合にText::Hatenaが古い時にフィルタメソッドの中で改めてnewしてるんだけど、T::P::Commaの形に合わせて書き直すと$configがすぐには取れない。でもまぁ、Text::Hatena 0.20のリリースは2007年2月だし、自分の環境で動けばいいから古い場合はパースせずにそのまま出力するだけに。

あと、以前から気になってたんだけど、T::P::Hatenaを使うと

Use of uninitialized value in concatenation (.) or string at (eval 1120) line 2433.

なんてエラーが出るんですよね。myapp_server.plでもFastCGIでも同じ。

バグ報告も上がってるんだけど、半年ほど放置されたままなのよね…

追いかけてみようかと思ったけど、Text::Hatenaは単独で成立してるモジュールじゃなくて、Parse::RecDescentを土台にしてるらしく、これを追うのが大変そうなので挫折したまんまorz

んー、悩ましい。とにかくメモリリークは解消て、ひとまずの危機は回避できたのでよしとする。