Topic: Memory leak (Read 1981 times)
I don't use any switches except -minimizetotray. Tried without it, tried deleting addr.dat but nothing changed. Connections number is flickering between 0 and 2. bitcoind works on my gateway and (I suppose) prevent connecting peers to my node because my node reports the same external IP as the gw. So when clients try to connect to my node they connect to bitcoind on the gw. But why can't my node connect to anybody even when it's NAT'd? I checked connection count on gw node and it's 100. Is there a hard limit of connecting to a single IP? Here is the full log of my local node: http://pastebin.com/0Aege9mb
You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.
IRC seems to be working. It ought to have other nodes to try.
There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside. Maybe there's something wrong in it.
Are you using -addnode?
IRC seems to be working. It ought to have other nodes to try.
There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside. Maybe there's something wrong in it.
Are you using -addnode?
Got that leak again with 0.3.13. Here is the log: http://pastebin.com/g0gqi7kx I cut it because the connecting-disconnecting repeats again and again without any change and censored the external static IP (it's detected correctly). The port 8333 is forwarded and is seen from the outside. The RES size of bitcoin grew up to 150 Mb when I shut it down.
Hmm, now the bug is gone though I remember how it was. That's the compiled release binary, 0.3.12 as I already mentioned. I didn't use -connect. Flickering was fast from 0 to 2 (less than half second) and then there was a pause in about a second with 0 connections. So the flicker itself was almost every second (not faster). Looks like it got connrefused instantly or such. I watched logs, sorry didn't saved them but there was nothing interesting just connect and disconnect without a reason.
I measured the RES memory with htop. It updates once per second that's why I can't see the real leak speed. Now the client tries to connect after startup and flickers 0-2, too, but just 5-10 times and then establishes one connection. Then it flickers between 1 and 3 and no leaks happen. Then connection number grows up to 40 or even more, everything is stable. To reproduce this try to switch off the network connection right after the client gets IPs from IRC so it will try to connect and fail.
I measured the RES memory with htop. It updates once per second that's why I can't see the real leak speed. Now the client tries to connect after startup and flickers 0-2, too, but just 5-10 times and then establishes one connection. Then it flickers between 1 and 3 and no leaks happen. Then connection number grows up to 40 or even more, everything is stable. To reproduce this try to switch off the network connection right after the client gets IPs from IRC so it will try to connect and fail.
Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the "-connect" switch?
Did you compile it or is this a release build, and what version?
I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?
The wait function on linux is:
inline void Sleep(int64 n)
{
boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}
If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.
Did you compile it or is this a release build, and what version?
I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?
The wait function on linux is:
inline void Sleep(int64 n)
{
boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}
If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.
I have an unusual configuration: on my headless gateway there is bitcoind running and on my desktop standart bitcoin is running (both Linux OpenSuSE, gateway 11.1, desktop 11.3, bitcoin 0.3.12 both). TCP port 8333 forwarded on gateway to the desktop (so gateway client can't has incoming connections). I don't know why but when I start desktop client after gateway's one the desktop client can't connect and flickers between 0 and 2 connections for a long time. Eventually it may connect but while it can't the memory leaks badly. About 200Kb/sec (each 0-2 change). It may not be noticed if the client connects instantly but in my case it doesn't. If I start first the desktop and then the headless client (after the desktop one has connected) everything is fine and no leaks (or they are little enough). I guess there is unfreed memory in bootstrap function or somewhere in the bootstrap process.
Jump to: