Hey, I've encountered an issue similar to this one:#207 . One key difference is that I useByteArrayProxy 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 addingSystem.gc() call right beforemdb_put makes the bug more frequent. I've been looking at the implementation of theByteArrayProxy and one thing caught my attention. Here's the code from it:

@Overrideprotectedvoidin(finalbyte[]buffer,finalPointerptr,finallongptrAddr) {finalPointerpointer =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 thepointer's underlying memory lifespan is actually longer than thepointer reference itself. From my understanding of howTransientNativeMemory injnr-ffi works, once aPointer has no reference to it, it's subject to be cleared by the "cleaner" thread. So there's a slim chance ofmdb_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.