(ITS#9155) LMDB: List of spill pages leaks after transaction

[babayants.alexander@gmail.com]

Full_Name: Alexander Babayants
Version: LMDB 0.9.24
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (188.170.78.53)


Hi!

ASAN shows that the list of spill pages is not freed after transaction:
=================================================================
==test==13046==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 20971376 byte(s) in 1 object(s) allocated from:
    #0 0x4bcbb2 in realloc (test+0x4bcbb2)
    #1 0x7f067ef5ed59 in mdb_midl_grow liblmdb/src/midl.c:135:8
    #2 0x7f067ef5ec83 in mdb_midl_append liblmdb/src/midl.c:162:7
    #3 0x7f067ef4456b in mdb_page_spill liblmdb/src/mdb.c:2077:13
    #4 0x7f067ef3960b in mdb_cursor_put liblmdb/src/mdb.c:6640:14
    #5 0x7f067ef5106c in mdb_put liblmdb/src/mdb.c:9027:7
    #6 0x4ec674 in main test.c:28:14
    #7 0x7f067b46d544 in __libc_start_main (/lib64/libc.so.6+0x22544)

SUMMARY: AddressSanitizer: 20971376 byte(s) leaked in 1 allocation(s).

Reproducible on LMDB 0.9.24 with the following code (anything doing
long write transaction will trigger this):
#include "lmdb.h"

int main(int argc,char * argv[])
{
    int rc;
    MDB_env *env;
    MDB_dbi dbi;
    MDB_val key, data;
    MDB_txn *txn;
    int kval;
    char sval[1024] = {0}; // fine to fill with zeroes

    rc = mdb_env_create(&env);
    rc = mdb_env_set_mapsize(env, 10ULL * 1024 * 1024 * 1024); // 10 GiB
    rc = mdb_env_open(env, "./testdb", 0, 0664);
    rc = mdb_txn_begin(env, NULL, 0, &txn);
    rc = mdb_dbi_open(txn, NULL, 0, &dbi);

    key.mv_size = sizeof(int);
    key.mv_data = &kval;
    data.mv_size = sizeof(sval);
    data.mv_data = sval;

    for (kval = 0; kval < 100'000'000; ++kval) {
        rc = mdb_put(txn, dbi, &key, &data, 0);
    }
    rc = mdb_txn_commit(txn);

    mdb_dbi_close(env, dbi);
    mdb_env_close(env);
    return 0;
}

>From my point of view the leak looks benign (=does not lead to
database corruption or such), but I didn't dive deep enough in LMDB
internals to be completely certain about that.

Regards,
Alexander Babayants.