Skip to contents

Changelog

Source: NEWS.md

mdbx 0.1.2

CRAN release: 2026-10-23

  • Fixes the problems CRAN’s valgrind check reported for 0.1.1, which led to its archival on 2026-10-19 (#30). All three are in how the bundled ‘libmdbx’ behaves under valgrind, or in what valgrind sees; nothing changes for code run natively.

    • mdbx_env_open() with the default geometry failed with “Invalid argument” under valgrind on a machine with a lot of RAM. ‘libmdbx’ reserves address space in proportion to RAM, and valgrind refuses a reservation that large. ‘libmdbx’ already retries with a smaller one, but only in builds made for valgrind; it now does so in every build.
    • A commit wrote a few bytes of uninitialised memory to disk: the unused tail of a free-list record, which no reader ever looks at. It is now zero-filled.
    • A transaction or environment deliberately given up after a ‘libmdbx’ assertion failure was reported as a “definitely lost” leak, and its internal lists, like those of an environment inherited by a forked process, as “possibly lost”. They are still given up, but are now kept reachable, so valgrind no longer counts them.

mdbx 0.1.1

CRAN release: 2026-09-28

CRAN release: 2026-09-28.

  • Fixes the undefined behaviour CRAN’s clang-UBSAN and gcc-UBSAN checks reported in the bundled ‘libmdbx’ sources. ‘libmdbx’ read and wrote 16-, 32- and 64-bit values through misaligned pointers on x86-64 and arm64; it is now built with MDBX_UNALIGNED_OK=0, which routes those accesses through byte copies. Three internal structures that ‘libmdbx’ deliberately indexes past their declared length are now C99 flexible array members, or are indexed through a pointer, so gcc’s -fsanitize=bounds-strict no longer reports them. Nothing observable changes: on-disk format, allocation sizes and results are identical.

mdbx 0.1.0

CRAN release: 2026-09-27

CRAN release: 2026-09-27.

  • Initial version.

  • mdbx_env_open() refuses a path this process already has open, naming the conflict, rather than passing on the lock file’s own failure (EAGAIN on macOS). Different spellings of one environment – a relative path against an absolute one, a symlinked directory, the data file of a subdir = TRUE layout – are recognised as the same path (#2).

  • mdbx_dbi_open() names the database it could not open, and says why create = TRUE needs a write transaction, instead of reporting libmdbx’s MDBX_NOTFOUND and EACCES (#3).

  • ?mdbx-concurrency no longer claims that two environments opened on the same file in one session are independent; they never were.

  • mdbx_dbi_drop() refuses to empty the main database while the environment holds any named database. A named database is a record in the main database, so ‘libmdbx’ purges every one of them along with it – silent, irreversible, and the opposite of what “removes every record but keeps the database” leads a caller to expect. Drop them by name first, or delete the main database’s keys individually.

  • mdbx_dbi_drop(db = NULL, delete = TRUE) is now an error. The main database records the named ones and cannot be deleted; ‘libmdbx’ silently ignores the request and reports success, so the caller was told a deletion had happened when it had not.