You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
lmdb closes and free()'s the memory used by MDB_cursor objects if they are created with a write transaction while cursors created with a read transaction must be manually closed/freed via mdb_cursor_close()
So far, so good. lmdbjava's Dbi.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's Cursor.close() even includes a helpful check to prevent clients from accidentally double free()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's Cursor owns two native resources, the MDB_cursor object and the KeyVal object which allocates memory for MDB_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