#環境によってまちまちですが、大体, 数十秒に一度リークしてしまいます。Gentoo Linux 3.7.1 x86_64とFreeBSD 6.2-RC1 i386上で確認しました。
#Linux x86_64だとあまりうちと違いがありそうにもないなあ。「数十秒に一度リーク」というのは具体的にどうなるのですか? メモリ使用量が増えるということか、それともクラッシュするということ?
#単に増え続けるだけで動作に問題はありません。
#その「数十秒に一度」どういうふうになるのですか? (何で観察していると何がどうなるのか、ということです)
#何度もすみません.. `top -p`で観察してると数十秒に一度Resident Sizeが増大していきます。
#おお、ok。確認しました。わずかづづですが増えて行きますね。
#sleepを0にしたり、nanosleepで1000nsとか短いウェイトを入れてみたら確かに増えないんですが、観察時点で既にRSSが(1秒sleepの時に比べて)大きいんで何とも言えないですねぇ。一定量でサチるなら、それまで徐々に増えて行くのは別に異常ではないので)。wasaoさんの環境で、上のコードが一定量でメモリ増加が止まるということですが、その止まった時のメモリサイズと、sleepを抜いた時に見えるメモリサイズがいくつだったかわかりますか?
#GC環境下でリークというのは、アクティブデータセットがboundedなのにメモリ使用量がunboundedに増えて行くことなので、「一定量でサチる」なら(その一定量が常識外れでなければ)正常動作の範囲です。単に回収が遅延されているだけです。デーモンでunboundedに増えていったなら、それは上のコードとは別の原因でリークが起きているんじゃないかという気がします。
#なお0.9.3.3ではforceにメモリリークのバグがあることがわかってて、lazy/delay/forceを使ったutil.streamなどの遅延ストリームを使うと漏れまくりです。lazy-sequenceの方は大丈夫だけど。
#止まった時のメモリサイズとsleepを抜いた時のメモリサイズは同じです。確かに他に原因がありそうです。ありがとうございました。
#あとありそうなのが、「weak-gc-robustでないデータ構造」というもので、例えばリストの尻尾にどんどん新たなデータ構造が追加されてゆく場合です。リストの頭の方はごみだからと安心していると、偽ポインタが頭の方をたまたま指していた場合にそれ以降のリストが回収されません。こういうunboundedに増えて行く構造では、使い終わったリストのcdrをset!してリンクを陽に切るといった配慮が要ることがあります。
#こんにちは、またまたmakikiについてです(今更ですがmakikiもここで良かったですか？)。cgi-handler経由で出力するときに、出力するデータが大きくなると(<buffered-output-port>のflushが2度以上呼ばれると)データが壊れてしまいます。こんな感じですかね:
#--- a/makiki.scm
+++ b/makiki.scm
@@ -579,7 +579,7 @@
(get-cgi-metavariables req script-name)]
[current-output-port
(make <buffered-output-port>
- :flush (^[v f] (enqueue! q v)
+ :flush (^[v f] (enqueue! q (u8vector-copy v))
(u8vector-length v)))])
(unwind-protect (proc "")
(close-output-port (current-output-port))))#makikiもここでいいですよー。ユーザが増えてくれると色々見つかってうれしいです。確かにvは上書きされ得るのでそのまま持ってちゃだめですね。ありがとうございます。
#pushしたけど、今見直してみたら後で全部つなげるんだからstring port使ってflushごとに中身を書き出して最後にget-stringすればいい気がしてきだ。
#>cryks これで動きますか? https://gist.github.com/4700835 cgi-handlerはまだテスト書いてないので… #あ、header+contentがu8vectorを要求するからだめだな。
##正常に動いています。
#先ほどのパッチはデバッグスタブが入ったままでした。今gitにpushしてあるのは直してあります。
#JavaScript書いてて、エラーの出る行をとりあえず;でコメントアウトして走らせてみるとまだそこでエラーが出てなぜだ、となる。
Gauche > Archives > 2013/02/03