possible memory leaks when not initialized properly about dashj HOT 10 CLOSED

it seems that even if ThreadCheckDarkSendPool is started the way I described above it stops after some time and the memory leak is back. It's probably better to use the lite mode.

from dashj.

LiteMode is to run a node without trying to get the list of masternodes, governance objects and governance votes. When LiteMode is OFF then the node tries to get a list of all of these other Dash objects. OFF is experimental and will soon become partially obsolete with the activation of Spork 15.

The Dash Wallet android app uses LiteMode and does not have issues finding peers. There is a fix for finding peers that will be added. I will comment later with the commit of that fix.

In the android app, we initialize with initDash(true, true). Will you be using InstantSend? If no, then you don't need any masternode functionality and the MasternodeManager will not be used.

from dashj.

Based on your first comment, it would seem that you want litemode ON as it seems to solve most of the problems. Additionally, in our next release of dashj 0.15.1, we will disable acquisition of masternode objects. This will resolve the memory leak of this: MasternodeManager#mapSeenMasternodePing, but won't address other issues. The other issues will need to be looked at further to determine why mapTxLockVotes is never emptied while litemode is OFF.

6ffd45c will address connectivity issues. Older nodes such as 0.12.3.x will not connect to dashj.

7eda2ce will ensure that dashj follows the correct chain (the same as the 0.13.x nodes).

from dashj.

We are investigating the memory leaks with mapTxLockVotes and found that in full verification mode, the confirmedHeight is not initialized, therefore TransactionLockVote.isExpired never returns true. This applies to several other InstantSend objects.

from dashj.

FYI over the weekend downloading of new transactions was stuck at #1033575 for me (don't know the reason yet) but it triggered another memory leak in org.bitcoinj.core.AbstractBlockChain#orphanBlocks. Its already reported in bitcoinj/bitcoinj#997

from dashj.

30e3911 will resolve the InstantSend related memory leaks.

My full node didn't get stuck on a particular block that I know of over the weekend. Regarding orphans, only with BloomFilters do they get removed. Of course in a full node, they stay in memory. I am not sure if we will get much help from the bitcoinj people, especially for full verification mode.

from dashj.

PR in bitcoinj: bitcoinj/bitcoinj#1738

from dashj.

The above PR for bitcoinj looks simple, I will test it out on dashj.

from dashj.

Testing complete. Memory leaks fixed.

from dashj.

So you're saying the above PR fixes your observed memory leak?

from dashj.