Java out of heap space - Githubissues

Multibit-Legacy / multibit-hd

Deprecated Bitcoin Wallet

https://multibit.org/blog/2017/07/26/multibit-shutdown.html

Other

171 stars 113 forks source link

Java out of heap space #688

Closed jim618 closed 8 years ago

jim618 commented 9 years ago

"stack_trace": "java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Unknown Source) ~[na:1.7.0_80] at java.lang.String.(Unknown Source) ~[na:1.7.0_80] at java.lang.StringBuilder.toString(Unknown Source) ~[na:1.7.0_80] at org.multibit.hd.core.services.WalletService.adaptTransaction(WalletService.java:443) ~[multibit-hd.jar:na] at org.multibit.hd.core.services.WalletService.getPaymentDataSet(WalletService.java:251) ~[multibit-hd.jar:na] at org.multibit.hd.ui.views.screens.payments.PaymentsScreenView.initialiseScreenViewPanel(PaymentsScreenView.java:113) ~[multibit-hd.jar:na] at

gary-rowe commented 9 years ago

We currently use the Oracle defaults here which are: 1/4 of total memory or 1Gb whichever is the smaller. So an 8Gb machine would only have a 1Gb maximum. It expands to fill the requirements.

We could modify this to allow more (e.g. -Xmx2048m) but I'm concerned that 1Gb isn't enough for our needs here. It would seem that this user has a huge number of transactions in the wallet or we have a memory leak.

Our first assumption should be memory leak, so it would be work running a soak test against a long-running collection of FEST test loops and observing the memory impact through jvisualvm.

gary-rowe commented 9 years ago

This is a sample from jvisualvm taken during a FEST test run. Looks like we've got a memory leak but it might be an artefact of the soft shutdown process:

Some observations:

threads are ratcheting up - this is likely the soft shut down effect since it holds references
class loading also climbs - probably the threads
heap memory consumption responds to garbage collection but there are dangling references - again the threads
CPU usage remains low - nothing is going into deadlock

More work needs to be done on cleaning up resources after soft shut down.

gary-rowe commented 8 years ago

Looking more deeply into this, it appears to be a bitcoinj issue in Transaction.toString(). There are a couple of loops over the inputs and output that could, in memory constrained conditions, exceed the available heap space.

Without more information on the system that experienced the problem (e.g. RAM size and the actual transaction ID to evaluate its size) I don't think we can ascertain the root cause of this.

If you agree, we can close this.

jim618 commented 8 years ago

Sounds like a likely hypothesis. Whilst we might be able to avoid the toString method (we'll use it in the raw transaction panel) we will NOT be able to avoid the transaction serialisation which most likely is going to exhibit the same behaviour.

I think if the user runs out of memory there is nothing much else to do rather that shutdown so this error is desired behaviour.

Closing.