メモリリーク

3 件のメッセージ 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));
}

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

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

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

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

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

-addnodeを使用しているか?