メモリリーク

5 件のメッセージ BitcoinTalk eurekafag, サトシ・ナカモト 2010年9月12日 — 2010年10月3日
eurekafag 2010年9月12日 原文 · 個別ページ

私は特殊な構成を使用している。ヘッドレスのゲートウェイではbitcoindが動作しており、デスクトップでは標準のbitcoinクライアントが動作している(両方ともLinux OpenSuSE、ゲートウェイは11.1、デスクトップは11.3、bitcoinは両方とも0.3.12)。TCPポート8333はゲートウェイからデスクトップに転送されている(そのためゲートウェイのクライアントは着信接続を受けられない)。原因は不明だが、ゲートウェイの後にデスクトップのクライアントを起動すると、デスクトップのクライアントが接続できず、長時間にわたって接続数が0と2の間を行き来する。最終的には接続できることもあるが、接続できない間はメモリが大量にリークする。約200KB/秒(0-2の切り替えのたびに)。クライアントが即座に接続できれば気づかない程度かもしれないが、私のケースではそうならない。デスクトップを先に起動し、その後ヘッドレスクライアントを(デスクトップが接続した後に)起動すれば、すべて正常に動作し、リークは発生しない(あるいは無視できる程度である)。ブートストラップ関数またはブートストラッププロセスのどこかで解放されていないメモリがあるのではないかと推測している。

0と2の間で接続が行き来しているのは、自分自身に接続している場合かもしれない。「-connect」スイッチを使っているか?

自分でコンパイルしたものか、それともリリースビルドか?バージョンは何だ?

200Kb/秒がどうなっているかわからない。接続試行の間に少なくとも0.5秒待つはずだ。0と2の接続間でどれくらい速く点滅しているか?1秒に2回より速いか?

Linuxでのwait関数は:

inline void Sleep(int64 n)
{
    boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}

これが正しく動作しなければ、ループを最速で回り続けることが可能だ。

eurekafag 2010年9月20日 原文 · 個別ページ

うーん、今はバグが消えたが、どんな状態だったかは覚えている。コンパイル済みのリリースバイナリで、既に述べた通り0.3.12だ。-connectは使っていなかった。フリッカリングは0から2まで高速で(0.5秒未満)、その後約1秒間0接続で停止した。フリッカー自体はほぼ毎秒だった(それ以上ではない)。connrefusedを即座に受けたような感じだ。ログを見ていたが、保存しなかった。接続と切断が理由もなく繰り返されるだけで、特に興味深いことはなかった。

htopでRESメモリを測定した。1秒ごとに更新されるため、実際のリーク速度は見えない。現在、クライアントは起動後に接続を試みて0-2の間でフリッカーするが、5〜10回だけで、その後1つの接続が確立される。その後1と3の間でフリッカーし、リークは発生しない。その後接続数は40以上に増え、すべて安定する。再現するには、クライアントがIRCからIPを取得した直後にネットワーク接続を切断し、接続を試みて失敗させればいい。

eurekafag 2010年10月3日 原文 · 個別ページ

0.3.13でまたリークが発生した。ログはこちら:http://pastebin.com/g0gqi7kx 接続と切断が何の変化もなく何度も繰り返されるのでカットし、外部の固定IPは検閲した(正しく検出されている)。ポート8333は転送されており外部から見える。シャットダウン時にBitcoinのRESサイズは150 MBまで増加していた。

自分自身に接続している。21回の接続試行すべてがバージョン31300(0.3.13)のノードに対するものだった。まだ全員が0.3.13にしているわけではない。

IRCは機能しているようだ。他に試すべきノードがあるはずだ。

切断後すぐに自分自身への接続を再試行しないようにする必要があるかもしれない。ただ、なぜそうなっているのかわからない。nLastTryをリセットしてキューの後ろに回すはずだが、ログには表示されていない。

addr.datを別の場所に移動してみてくれ。その中に何か問題があるかもしれない。

-addnodeを使用しているか?