lmdb closes andfree()'s the memory used byMDB_cursor objects if they are created with a write transaction while cursors created with a read transaction must be manually closed/freed viamdb_cursor_close()

So far, so good. lmdbjava'sDbi.openCursor() includes documentation to this effect

   ...A cursor in a write-transaction can   * be closed before its transaction ends, and will otherwise be closed when   * its transaction ends. A cursor in a read-only transaction must be closed   * explicitly, before or after its transaction ends...

lmdbjava'sCursor.close() even includes a helpful check to prevent clients from accidentally doublefree()ing the native cursor object by ensuring that the method throws an error if the cursor was opened with a write transaction that is now closed. Very nice.

Now for the problem: lmdbjava'sCursor ownstwo native resources, theMDB_cursor objectand the KeyVal object which allocates memory forMDB_vals. KeyVal's native memory cannot be disposed of by the client if the transaction was writeable and closed first.

Suggest updating close to independently dispose of both native resources so that the (useful) double free protection doesn't leak the KeyVal