Bisq crashes with OutOfMemoryError: Java heap space on a fresh data directory

[Gummihund]

Bisq crashes with OutOfMemoryError: Java heap space — even on a brand new data directory

Version: Bisq v1.10.4

Symptom: Bisq shuts down with this in bisq.log, often while parsing a new DAO/BSQ block:

ERROR b.c.s.CommonSetup: OutOfMemoryError occurred. We shut down. java.lang.OutOfMemoryError: Java heap space
    at bisq.core.dao.monitoring.DaoStateMonitoringService.createHashFromBlock
    at bisq.core.dao.state.DaoStateSnapshotService.onDaoStateChanged

This happens even with a completely fresh data directory, so it does not appear to be caused by accumulated wallet/DAO data. The Profiler lines just above the crash show:

INFO b.c.u.Profiler: Total memory: 2 GB; Used memory: 1,913 GB; ... Max memory: 2 GB

Likely root cause: the JVM options bundled with the desktop installer set -XX:MaxRAM=8g but no explicit -Xmx. Without an explicit -Xmx, the G1 collector's default maximum heap is derived as a fraction of MaxRAM, which caps the heap at approximately 2 GB regardless of how much RAM the machine actually has. During DAO state hash-chain computation on a new block, that ceiling appears to be insufficient and the JVM throws an OOM error.

Workaround: add an explicit -Xmx to the app's JVM options, overriding the MaxRAM-derived default. The value should be adjusted to the available RAM; 4g is a reasonable value on a machine with at least 8 GB RAM.

Linux (.deb install)

1. Back up the config file:

   sudo cp /opt/bisq/lib/app/Bisq.cfg /opt/bisq/lib/app/Bisq.cfg.bak

2. Edit it:

   sudo nano /opt/bisq/lib/app/Bisq.cfg

3. In the [JavaOptions] section, add:

   java-options=-Xmx4g
   

4. Save the file and restart Bisq.

This file belongs to the installed package. A future Bisq update or reinstall via .deb may overwrite it and require the workaround to be reapplied.

Windows

1. Locate the application config file, typically:

   C:\Program Files\Bisq\app\Bisq.cfg
   

   The exact path may vary depending on the version or custom installation location. The file should be in the app folder next to Bisq.exe.

2. Back up Bisq.cfg as Bisq.cfg.bak.

3. Open Bisq.cfg in a text editor with administrator privileges.

4. In the [JavaOptions] section, add:

   java-options=-Xmx4g
   

5. Save the file and restart Bisq.

This setting may also be reset by a future Bisq update until the installer supplies an appropriate explicit maximum heap setting.

Log

bisq.log

[boring-cyborg]

Thanks for opening your first issue here!

Be sure to follow the issue template. Your issue will be reviewed by a maintainer and labeled for further action.

[onlymarcus]

Here's a version you can post directly. I based the Windows path on how Bisq's installer is packaged (jpackage), but suggest readers confirm their actual install path since it can vary by version/custom install location.

---

Bisq crashes with OutOfMemoryError: Java heap space — even on a brand new data directory

Symptom: Bisq shuts down with this in bisq.log, often while parsing a new DAO/BSQ block:

ERROR b.c.s.CommonSetup: OutOfMemoryError occurred. We shut down. java.lang.OutOfMemoryError: Java heap space
	at bisq.core.dao.monitoring.DaoStateMonitoringService.createHashFromBlock
	at bisq.core.dao.state.DaoStateSnapshotService.onDaoStateChanged

This happens even with a completely fresh data directory, so it's not about accumulated wallet/DAO data size — check the Profiler lines just above the crash:

INFO b.c.u.Profiler: Total memory: 2 GB; Used memory: 1,913 GB; ... Max memory: 2 GB

Root cause: the JVM options bundled with the desktop installer set -XX:MaxRAM=8g but no explicit -Xmx. Without an explicit -Xmx, the G1 collector's default max heap is derived as a fraction of MaxRAM — which caps the heap at ~2GB regardless of how much RAM your machine actually has. During DAO state hash-chain computation on a new block, that 2GB ceiling isn't enough and the JVM throws OOM.

Fix: add an explicit -Xmx to the app's JVM options, overriding the MaxRAM-derived default. Adjust the value to your available RAM (4g is a safe default on a 8GB+ machine).

Linux (.deb install)

1. Back up the config file first:

   sudo cp /opt/bisq/lib/app/Bisq.cfg /opt/bisq/lib/app/Bisq.cfg.bak

2. Edit it:

   sudo nano /opt/bisq/lib/app/Bisq.cfg

3. In the [JavaOptions] section, add a new line (anywhere in that section, e.g. right after java-options=-XX:MaxRAM=8g):

   java-options=-Xmx4g
   

4. Save and close, then restart Bisq.

Note: this file belongs to the installed package. A future Bisq update/reinstall via .deb will overwrite it and reset the heap cap — you'll need to reapply this line after each update.

Windows

1. Locate the app config file, typically:

   C:\Program Files\Bisq\app\Bisq.cfg
   

   (confirm the exact path for your install — it sits next to Bisq.exe, inside the app folder).
2. Back it up first (copy Bisq.cfg to Bisq.cfg.bak in the same folder).
3. Open Bisq.cfg in a text editor with administrator privileges (Notepad run as admin, since the file lives under Program Files).
4. In the [JavaOptions] section, add:

   java-options=-Xmx4g
   

5. Save and restart Bisq.

Same caveat applies: this gets reset on the next Bisq update, so you'll need to redo it each time until the default -Xmx in the installer itself is fixed upstream.

[Gummihund]

Thank you, @onlymarcus — this is very helpful. I have updated the issue title and description with the complete error context, likely cause, and the Linux/Windows workaround you provided. The crash also occurs with a fresh data directory, which should help distinguish it from accumulated wallet or DAO data. I appreciate you taking the time to turn the original report into a clear, reproducible bug report.