bitcoind crashes when RPC server encounters an error #6427

I am encountering a persistent error that happens several times a day that results in the bitcoind (v. 100200) process crashing. My instance is an 8GB (AWS t2.large) and my memory logs reveal this is not related to a shortage of available memory (it dies with several gigs available). I should note there is another process that his hitting bitcoind via RPC and retrieving blockchain data only (blocks and transactions).

In debug.log, I have encountered the following that may reveal a problem with the RPC server:

2015-07-09 19:22:26 socket recv error Connection timed out (110) 2015-07-09 19:23:30 dumpaddr thread stop 2015-07-09 19:23:30 opencon thread interrupt 2015-07-09 19:23:30 addcon thread interrupt 2015-07-09 19:23:30 msghand thread interrupt 2015-07-09 19:23:30 net thread interrupt 2015-07-09 19:23:30 Shutdown: In progress... 2015-07-09 19:23:30 StopNode() 2015-07-09 19:23:30 Shutdown: done 2015-07-09 19:27:32

This is another debug.log before the processes terminated:

2015-07-09 16:12:09 socket send error Broken pipe (32) 2015-07-09 16:12:39 ping timeout: 1200.192793s 2015-07-09 16:22:17 socket recv error Connection reset by peer (104) 2015-07-09 16:24:28

The timing between the process crashing and the recent spam attacks are correlated.

Could that be related to #6412?

I believe the RPC server is also holding on to old queried data as well since bitcoind is consuming a lot of memory on my machine which only happens when using it a lot.

Are you willing/able to share the code that is querying for blocks/transactions? If not, can you describe in detail how it utilizes the RPC interface?

Still happening with latest (110000) and crashing on a 16GB box. With txindex=1 in bitcoin.conf, I am using an in-house blockchain parser that uses only the following RPC commands:

• getrawtransaction
• getrawmempool
• getblock
• getblockcount

There is clearly a memory leak with one of these commands, resulting in memory being completely consumed before crashing that requires constant restarting.

Memory usage doesn't look abnormal, 1747M virtual 632M resident.

Can you run bitcoind in gdb to get a traceback when the crash happens?

@thallium205 it might be worth showing statistics of a bitcoind instance on the same box that does not use the RPC commands, and another instance that does allow use of the RPC commands. If the RPC usage is the only difference, and the memory usage still spikes, then, it at least hints at causality.

Closing due to inactivity