Hey, I've encountered an issue similar to this one: #207 . One key difference is that I use ByteArrayProxy instead of any direct buffers.

I'm using the newest lmdbjava along with lmdb binary built from newest version (commit).

So I've been following the steps from the mentioned issue and it's true that adding System.gc() call right before mdb_put makes the bug more frequent. I've been looking at the implementation of the ByteArrayProxy and one thing caught my attention. Here's the code from it:

  @Override
  protected void in(final byte[] buffer, final Pointer ptr, final long ptrAddr) {
    final Pointer pointer = MEM_MGR.allocateDirect(buffer.length);
    pointer.put(0, buffer, 0, buffer.length);
    ptr.putLong(STRUCT_FIELD_OFFSET_SIZE, buffer.length);
    ptr.putAddress(STRUCT_FIELD_OFFSET_DATA, pointer.address());
  }

What worries me is that the pointer's underlying memory lifespan is actually longer than the pointer reference itself. From my understanding of how TransientNativeMemory in jnr-ffi works, once a Pointer has no reference to it, it's subject to be cleared by the "cleaner" thread. So there's a slim chance of mdb_put operating on memory that has been cleared already. Am I correct?

What I'm currently testing is adding a static list of references to pointers inside the proxy, and then manually clearing it once transaction is done: bdsystems@9e5eee9
So far this seems to work correctly, but with these kind of issues testing has to take time.

What do you think? Could that be the bug, or is my hypothesis wrong? I'm new to java memory management and jnr-ffi in particular so please correct me if my reasoning is faulty.