JVM Crash in LMDB Native Code via lmdbjava

[bernardladenthin]

https://github.com/bernardladenthin/BitcoinAddressFinder/actions/runs/14339219251/job/40194071370

Issue:
A segmentation fault (SIGSEGV) occurs during test execution when using lmdbjava, crashing the JVM in native code (mdb_txn_renew0).

Native lib: lmdbjava-native-library

SIGSEGV at mdb_txn_renew0+0x13e

I assume the issue is sporadic and may be related to the Maven Surefire plugin's forked JVMs.
jacoco/jacoco#917

hs_err_pid2053.log
job-logs.txt
2025-04-08T15-58-46_111-jvmRun1.txt

[bernardladenthin]

Disabling JaCoCo and setting forkCount to 0 in the matrix CI and assembly builds should avoid the problem. See:

• b8804d7

[bernardladenthin]

b2c0517

I'm sure the method is not thread safe from a native point of view, synchronized works.

@Override
public synchronized boolean containsAddress(ByteBuffer hash160) {
    try (Txn<ByteBuffer> txn = env.txnRead()) {
        ByteBuffer byteBuffer = lmdb_h160ToAmount.get(txn, hash160);
        return byteBuffer != null;
    }
}

[bernardladenthin]

I got an exception here also:

@Override
public boolean containsAddress(ByteBuffer hash160) {
    Txn<ByteBuffer> txn;
    synchronized (env) {
        txn = env.txnRead();
        try (txn) {
            ByteBuffer byteBuffer = lmdb_h160ToAmount.get(txn, hash160);
            return byteBuffer != null;
        }
    }
}

surefire-reports-ubuntu-latest-microsoft-java21.zip

[bernardladenthin]

Likely an LMDB / lmdbjava-level issue, not BAF code — see lmdbjava/lmdbjava#253, which reports the same native crash signature (SIGSEGV in mdb_txn_renew0+0x13e) under heavy multithreaded read access (env.txnRead() / Dbi.get()). There the reporter tried several synchronization variants without fixing it and suspects a thread-safety/JNI issue inside lmdbjava itself; the upstream issue is still open with no resolution.

Keeping this open and tracking upstream.

---

Generated by Claude Code

[bernardladenthin]

Added an opt-in concurrency stress harness to help reproduce/validate this: src/test/java/net/ladenthin/bitcoinaddressfinder/persistence/lmdb/LmdbConcurrentReadStressTest.java.

What it does: spins N threads doing concurrent read-only containsAddress() lookups against a small test LMDB — each thread with its own direct key buffer and its own env.txnRead() per lookup (the same pattern ConsumerJava uses) — to provoke the sporadic native SIGSEGV in mdb_txn_renew0.

It is off by default (a normal mvn test skips it). A real reproduction is a native crash that kills the JVM and is probabilistic, so a passing run proves nothing — only a crash is meaningful; that's why it's gated and not in the default suite.

Run it:

mvn test -Dtest=LmdbConcurrentReadStressTest \
  -Dnet.ladenthin.bitcoinaddressfinder.lmdbStressTest=true \
  -Dnet.ladenthin.bitcoinaddressfinder.lmdbStressTest.threads=64 \
  -Dnet.ladenthin.bitcoinaddressfinder.lmdbStressTest.seconds=60

(threads / seconds tunable; also honours -Dnet.ladenthin.bitcoinaddressfinder.disableLMDBTest.)

Intended use: run it repeatedly before and after the env-flag change suggested upstream in lmdbjava/lmdbjava#253 — i.e. open the read env with EnvFlags.MDB_NOTLS and set maxReaders >= thread count (and reconsider MDB_NOLOCK) — to gauge whether that removes the crash. The read path already uses one short-lived txnRead() per call per thread (not a shared Txn); the current read env uses MDB_RDONLY_ENV | MDB_NOLOCK without MDB_NOTLS, which is the prime suspect for the mdb_txn_renew0 reader-slot crash.

Sanity check in CI-like env: enabled, 8 threads / 3s → ~1.5M reads, 0 errors, no crash (expected for a short low-thread run). Keeping this issue open to track the upstream fix + the flag change.

---

Generated by Claude Code