René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Memory leak possible if transaction closed before cursor.","articleBody":"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()`\r\n\r\nSo far, so good. lmdbjava's `Dbi.openCursor()` includes documentation to this effect \r\n```\r\n   ...A cursor in a write-transaction can\r\n   * be closed before its transaction ends, and will otherwise be closed when\r\n   * its transaction ends. A cursor in a read-only transaction must be closed\r\n   * explicitly, before or after its transaction ends...\r\n```\r\n\r\nlmdbjava'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.\r\n\r\nNow for the problem: lmdbjava's `Cursor` owns *two* native resources, the `MDB_cursor` object *and* the KeyVal object which allocates memory for `MDB_val`s. KeyVal's native memory cannot be disposed of by the client if the transaction was writeable and closed first.\r\n\r\nSuggest updating close to independently dispose of both native resources so that the (useful) double free protection doesn't leak the KeyVal","author":{"url":"https://github.com/danielcranford","@type":"Person","name":"danielcranford"},"datePublished":"2022-07-05T16:02:58.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/197/lmdbjava/issues/197"}